RFR: JDK-8136991: [REDO] Additional number of processed references printed with -XX:+PrintReferenceGC after JDK-8047125
Kim Barrett
kim.barrett at oracle.com
Thu Sep 24 22:40:19 UTC 2015
On Sep 23, 2015, at 8:19 AM, Bengt Rutisson <bengt.rutisson at oracle.com> wrote:
>
> Updated webrev:
> http://cr.openjdk.java.net/~brutisso/8136991/webrev.04/
------------------------------------------------------------------------------
src/share/vm/gc/shared/referenceProcessor.cpp
195 GCRefTraceTime(ReferenceType ref_type, bool doit, GCTimer* timer, GCId gc_id, size_t count) :
196 _gc_trace_time(reference_type_to_short_string(ref_type), doit, false, timer, gc_id) {
197 log_ref_count(count);
198 }
The _gc_trace_time printing is controlled by the doit parameter, while
log_ref_count is (internally) controlled by PrintReferenceGC and
PrintGCDetails. Those two are presently equivalent, but that isn't at
all obvious and could change later. I think the call to log_ref_count
ought to be conditional on doit here.
If the call to log_ref_count for JNI Weak References were similarly
conditional on trace_time, then log_ref_count wouldn't need any
internal conditionalization at all.
------------------------------------------------------------------------------
src/share/vm/gc/shared/referenceProcessor.cpp
236 GCRefTraceTime tt(REF_SOFT, trace_time, gc_timer, gc_id, stats.soft_count());
I don't understand the point of the change here and in later similar
places to replace the string name of the reference type with the
REF_XXX reference type. It is this change that seems to drive the
addition of reference_type_to_[short_]string. And
reference_type_to_string appears to be unused in these changes.
------------------------------------------------------------------------------
src/share/vm/gc/shared/referenceProcessor.cpp
[removed comment]
246 // Process cleaners, but include them in phantom statistics. We expect
247 // Cleaner references to be temporary, and don't want to deal with
248 // possible incompatibilities arising from making it more visible.
This comment was removed. (Actually, it was moved to the earlier
capture of the counts.) However, it is still applicable here in that
we include cleaner processing in the time associated with phantom
reference processing.
------------------------------------------------------------------------------
Regarding GCRefTraceTime, GCCMTraceTime, GCTraceTime
Version 04 webrev has GCTraceTime derived from StackObj, with
GCRefTraceTime and GCCMTraceTime having a GCTraceTime member and
derived from nothing.
Being derived from nothing is supposed to be disallowed; quoting from
allocation.hpp:
All classes in the virtual machine must be subclassed by one of the
following allocation classes.
Better would be to separate out the present implementation of
GCTraceTime into a helper class (let's call it GCTraceTimeImpl), which
is a VALUE_OBJ_CLASS_SPEC class. Then GCTraceTime, GCCMTraceTime, and
GCRefTraceTime all derive from StackObj and have a GCTraceTimeImpl
member.
------------------------------------------------------------------------------
More information about the hotspot-gc-dev
mailing list