JDK-8180932 : Parallelize safepoint cleanup
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 10
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2017-05-24
  • Updated: 2019-05-22
  • Resolved: 2017-07-21
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 10
10 b21Fixed
Related Reports
Relates :  
JDK-8185273 - Test8004741.java crashes with SIGSEGV in JDK10-hs nightly
Relates :  
JDK-8185102 - TestSAServer.java fails due to "sun.jvm.hotspot.types.WrongTypeException: field "_stack_traversal_mark"
Relates :  
JDK-8153224 - Monitor deflation prolong safepoints
Relates :  
JDK-8186837 - Memory ordering nmethod, _state and _stack_traversal_mark
Relates :  
JDK-8132849 - Increased stop time in cleanup phase because of single-threaded walk of thread stacks in NMethodSweeper::mark_active_nmethods()
Relates :  
JDK-8184751 - Provide thread pool for parallel safepoint cleanup
Relates :  
JDK-8185580 - Refactor Threads::possibly_parallel_oops_do() to use Threads::parallel_java_threads_do()
Description
Some operations in safepoint cleanup have been observed to (sometimes) take significant time. Most notably, idle monitor deflation and nmethod marking stick out in some popular applications and benchmarks.

I propose to:
- parallelize safepoint cleanup processing
- enable to hook up idle monitor deflation and nmethod marking to GC VM ops, if GC can support it (resulting in even more efficient deflation/nmethod marking)
Comments
Seems to be related to JDK-8132849.
24-05-2017