JDK-6965184 : possible races in make_not_entrant_or_zombie
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: hs19
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris_9
  • CPU: sparc
  • Submitted: 2010-06-29
  • Updated: 2016-08-25
  • Resolved: 2011-04-23
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-6974176 - ShouldNotReachHere, instanceKlass.cpp:1426
Relates :  
JDK-6950075 - nmethod sweeper should operate concurrently
Relates :  
JDK-8153134 - Infinite loop in handle_wrong_method in jmod
Relates :  
JDK-6968385 - malformed xml in sweeper logging
Description
While investigating the recent sweeper problems I identified some potential problems races around state management because of greater concurrency in the new scheme.
Comments
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/2a47bd84841f
21-07-2010
EVALUATION 6965184: possible races in make_not_entrant_or_zombie Reviewed-by: kvn While investigating the sweeper concurrency problems I identified a bunch of minor issues that could lead to races. NMethod groups a bunch of flags into a struct using bitfield which was okay in the past because they were either written by the constructor, at a safepoint or with a single lock held. Now some of those fields are written under one lock and some are written under another so they should be separated. I've done away with nmFlags all together and moved a bunch of common initialization into a new method. I also deleted a other of unused or dead things. In make_not_entrant_or_zombie, all the zombie logic used to be performed at a safepoint but now it can happen concurrently so the logic that is executed outside of the Patching_lock has to be more careful. All the not_entrant logic has been moved into the region protected by the Patching_lock. The link between the nmethod and the methodOop is also broken ealier though a strong reference to the methodOop is maintained to make sure it stays alive. There were problems with the maintenance of _sweep_started and _invocations that could mistakenly allow another thread into possibly_sweep but only if there was no work to be done. Also threads besides the sweeping thread could clear _sweep_started. The sweeper divides the cache based on the number of blobs even though it only works on nmethod, so I added a nof_nmethods count along with a nof_adapters count just for informational purposes. As a cleanup I also deleted the dead and unused VTune logic since it doesn't work and VTune uses JVMTI agents these days. Tested with NSK jvmti,jdi,jdb,hprof,jit,regression and JDI_REGRESSION tests.
12-07-2010
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/2a47bd84841f
09-07-2010