JDK-8191733 : Fix for JDK-8160548 causes ForceEarlyReturn007 JDI test to assert
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 10
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2017-11-21
  • Updated: 2017-11-21
  • Resolved: 2017-11-21
Related Reports
Duplicate :  
JDK-8191688 - Assert failed in > 200 tests: failed dependencies, but counter didn't change
Relates :  
JDK-6328518 - nsk/jvmti/scenarios/hotswap/HS101/hs101t004 fails intermittently with assertion
Description
ForceEarlyReturn007 is marked as quarantine so it has not been getting run as part of the nsk.jdi testlist. However, it was quarantined due to JDK-8160548, which was closed about a month ago as CNR, so it should not be quarantined anymore. Just to be sure I tried running it again yesterday, and noticed it was asserting again. However, the assert was different than for JDK-8160548. I tracked it down to the changes introduced by JDK-8160548 yesterday.

# Internal Error (/scratch/opt/mach5/mesos/work_dir/slaves/55769d18-ab0b-47ef-be98-151e5144ba9a-S41969/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/c4c8a46f-a98a-45c9-8591-42470ad27b27/runs/9ed2b119-bba5-44a6-bd2c-cfe799bd207c/workspace/open/src/hotspot/share/ci/ciEnv.cpp:957), pid=26394, tid=26425
# assert(counter_changed) failed: failed dependencies, but counter didn't change

Current thread (0x00007efecc3d7800): JavaThread "C2 CompilerThread2" daemon [_thread_in_vm, id=26425, stack(0x00007efe846e9000,0x00007efe847ea000)]

Current CompileTask:
C2: 8938 713 4 nsk.share.jpda.ForceEarlyReturnTestThread::executeMethod (1245 bytes)

V [libjvm.so+0x181f112] VMError::report_and_die(int, char const*, char const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x162
V [libjvm.so+0x181fedf] VMError::report_and_die(Thread*, char const*, int, char const*, char const*, __va_list_tag*)+0x2f
V [libjvm.so+0xb2d59d] report_vm_error(char const*, int, char const*, char const*, ...)+0xdd
V [libjvm.so+0x909900] ciEnv::validate_compile_task_dependencies(ciMethod*) [clone .part.105]+0x290
V [libjvm.so+0x90f4e2] ciEnv::register_method(ciMethod*, int, CodeOffsets*, int, CodeBuffer*, int, OopMapSet*, ExceptionHandlerTable*, ImplicitExceptionTable*, AbstractCompiler*, bool, bool, RTMState)+0x702
V [libjvm.so+0xa95446] Compile::Compile(ciEnv*, C2Compiler*, ciMethod*, int, bool, bool, bool, DirectiveSet*)+0x1766
V [libjvm.so+0x8ae042] C2Compiler::compile_method(ciEnv*, ciMethod*, int, DirectiveSet*)+0x2e2
V [libjvm.so+0xa9faae] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x38e
V [libjvm.so+0xaa06a1] CompileBroker::compiler_thread_loop()+0x241
V [libjvm.so+0x177950e] JavaThread::thread_main_inner()+0x22e
V [libjvm.so+0x1779754] JavaThread::run()+0x184
V [libjvm.so+0x14b333a] thread_native_entry(Thread*)+0xfa
C [libpthread.so.0+0x7dc5] start_thread+0xc5
Comments
This looks suspicious: if (env->jvmti_can_hotswap_or_post_breakpoint() && can_be_compiled()) { // 6328518 check hotswap conditions under the right lock. MutexLocker locker(Compile_lock); if (Dependencies::check_evol_method(h_m()) != NULL) { _is_c1_compilable = false; _is_c2_compilable = false; } } else { If we still allow the method to be inlined, this this workaround for 6328518 won't work. Do we need a new _refuse_to_parse flag instead?
21-11-2017
Backing out JDK-8160548 makes nsk/jvmti/RedefineClasses/StressRedefineWithoutBytecodeCorruption pass, which is one of the failures for 8191688.
21-11-2017
Same symptom as 8191688.
21-11-2017