request for review (M), 6458402: 3 jvmti tests fail with CMS and +ExplicitGCInvokesConcurrent
keith.mcguigan at oracle.com
Thu Dec 30 23:03:02 UTC 2010
My last request for a code review this year, I promise!
This fix adds the missing JVMTI GC callbacks for CMS:
Existing mechanism used a stack-allocated JvmtiGCMarker to bracket the
GC operation. The destructor, in addition to posting the gc-end
event, also did come bookkeeping work for JvmtiBreakpoints and
JvmtiTagMap. Unfortunately, this cleanup work needs to be done at
safepoint, but for CMS, gc-end may not happen at safepoint, so the
JVMTI gc-end event posting has to be decoupled from the other work to
update the data structures.
I changed the mechanism so that the bookkeeping work could be done
during the oop-iteration phase instead of being invoked from the
JvmtiGCMarker destructor. This allowed the JvmtiGCMarker to be used
outside of a safepoint. The bookkeeping code was modified to operate
during oop iteration. The changes to update the JvmtiBreakpoint cache
was rather trivial, but the changes to JvmtiTagMap were more involved.
The JVMTI tag map code had maintained a separate hashtable of JNI weak
references for each generation, and rehashed the required tables after
a GC. I unified these into a single table containing raw oops
instead, and added a weak oop iteration over the single table
instead. Only oops that moved need to be rehashed, and this is now
done in-line rather than as a full rehash step at the end of GC. The
separate tables were intended to reduce the work done during a minor
GC, but since each entry contained a weak reference, all tagged
objects needed to be visited in JNIHandles::weak_oops_do() anyway.
Using one table and iterating the contained oops as weak roots appears
to work well too, as only the entries with oops that move are
rehashed. So during a minor collection, all oops will be seen (as
before in JNIHandles), but only the oops in the young generation will
move and need to be rehashed. A sample program that tagged 8M objects
(half in each generation) showed a 10+% performance improvement in
time spent in safepoint.
During addition of the JVMTI callbacks, I noticed the DTrace callbacks
were missing for CMS too. I ran with Tony's idea of putting the
DTrace probes in a marker object and unified it so there's only one
marker to use which performs the work needed for JVMTI as well as for
DTrace. I added this as SvcGCMarker and replaced the locations of
JvmtiGCMarker and notify_gc_[begin/end] with the new marker.
More information about the hotspot-gc-dev