JDK-6950075 : nmethod sweeper should operate concurrently
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: hs18
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_9
  • CPU: sparc
  • Submitted: 2010-05-05
  • Updated: 2010-09-24
  • Resolved: 2010-06-01
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 6 JDK 7 Other
6u21pFixed 7Fixed hs19Fixed
Related Reports
Relates :  
JDK-6956931 - assert(SafepointSynchronize::is_at_safepoint()) failed: must be executed at a safepoint
Relates :  
JDK-6956958 - assert(is_clean() || is_call_to_compiled() || is_call_to_interpreted() || is_optimized() || is_megam
Relates :  
JDK-6965184 - possible races in make_not_entrant_or_zombie
Description
The nmethod sweeper currently does it's work at the end of every safepoint which increases the period of time that all threads are stopped.  It should operate concurrently in another thread.
Comments
EVALUATION 6950075: nmethod sweeper should operate concurrently Reviewed-by: never, kvn Contributed-by: ###@###.### In the current JVM, the nmethod sweeper runs during each safepoint, and may return early if there is no work to do. It periodically scans the thread stacks to determine if not-entrant nmethods have no lingering active stack frames and can be converted to zombies. It then walks the code cache promoting not-entrant nmethods to zombies if possible and deleting the zombies. It walks a fraction of the code cache in each turn, set by NmethodSweepFraction, which is 4 by default. When the whole code cache is traversed and no progress can be made, the sweeper will go idle until another nmethod becomes not- entrant, starting the process over again. In applications with a lot of compiled code, walking the code cache can take many milliseconds, contributing to long safepoint pause times, reducing application throughput. This change makes part of the sweeper work concurrent to reduce the safepoint pause time. In this webrev, the stack scans continue to happen at safepoint time but the code cache traversal is concurrent with the application. The traversal work runs on the compiler threads where they will check to sweep each time passing through the compile queue. They may take the code cache and stub related locks as necessary to do the sweeping safely. Only one thread will sweep at a time and it preserves the existing way of traversing in chunks by NmethodSweepFraction. There are a few adjustments to the checks regarding the code cache unloading feature to accommodate these changes. Also I added new convenience methods such as CodeCache::next_nmethod() for simple traversal. I worked out this design with Tom Rodriguez over the last month or so. We'd like some other eyes on it.
18-05-2010
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/bfe29ec02863
18-05-2010