JDK-8042570 : Excessive number of tests timing out on nightly testing due to fix for 8040798
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 9
  • Priority: P1
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2014-05-07
  • Updated: 2019-09-13
  • Resolved: 2014-05-07
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8 JDK 9
8u40Fixed 9 b14Fixed
Related Reports
Duplicate :  
Relates :  
Description
An excessive number of tests are timing out on nightly testing of jdk9/hs/hotspot
after  hs-comp/hotspot was pushed up to that repo. The fix for 8040798 is
the suspicious culprit. 
Timeouts mostly on solaris and linux, windows does not seem to be affected.
Comments
verified by nightly testing
26-07-2017

good to see the cause is known. Can you push the fix as soon as you can, so that it makes it to jdk9/hs/hotspot this week, otherwise I won't be able to snapshot that repo this week, since that will propagate the problem to other repos. If that's not feasible, then consider pushing a backout for the 8040798 fix
07-05-2014

ILW=deadlock or lock contention, high, none=HHH=P1
07-05-2014

I think that Vladimir's analysis is correct. The locks that I introduced in JDK-8040798 can cause the deadlock, since AdvancedThresholdPolicy::select_task() is called while holding the MethodCompileQueue_lock. AdvancedThresholdPolicy::select_task() can reach a safepoint when the destructor of CompileTaskWrapper is called. Another instance where the MethodCompileQueue_lock is hold and a safepoint can be reached is in ciEnv::register_method(). This can cause a deadlock, since compileBroker::mark_on_stack() is called at a safepoint.
07-05-2014

Could be related to 8040798 next changes (added locks): void CompileBroker::mark_on_stack() { - if (_c2_method_queue != NULL) { - _c2_method_queue->mark_on_stack(); + if (_c2_compile_queue != NULL) { + MutexLocker locker(_c2_compile_queue->lock()); + _c2_compile_queue->mark_on_stack(); } - if (_c1_method_queue != NULL) { - _c1_method_queue->mark_on_stack(); + if (_c1_compile_queue != NULL) { + MutexLocker locker(_c1_compile_queue->lock()); + _c1_compile_queue->mark_on_stack(); } }
07-05-2014