United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6965184 possible races in make_not_entrant_or_zombie
JDK-6965184 : possible races in make_not_entrant_or_zombie

Details
Type:
Bug
Submit Date:
2010-06-29
Status:
Closed
Updated Date:
2011-04-23
Project Name:
JDK
Resolved Date:
2011-04-23
Component:
hotspot
OS:
solaris_9
Sub-Component:
compiler
CPU:
sparc
Priority:
P4
Resolution:
Fixed
Affected Versions:
hs19
Fixed Versions:
hs19 (b04)

Related Reports
Backport:
Backport:
Backport:
Backport:
Relates:
Relates:
Relates:

Sub Tasks

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-comp/hotspot/rev/2a47bd84841f
                                     
2010-07-09
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.
                                     
2010-07-12
EVALUATION

http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/2a47bd84841f
                                     
2010-07-21



Hardware and Software, Engineered to Work Together