RFR: JDK-8136991: [REDO] Additional number of processed references printed with -XX:+PrintReferenceGC after JDK-8047125
Kim Barrett
kim.barrett at oracle.com
Fri Sep 25 18:56:32 UTC 2015
On Sep 25, 2015, at 4:27 AM, Bengt Rutisson <bengt.rutisson at oracle.com> wrote:
>
> On 2015-09-25 00:40, Kim Barrett wrote:
>> 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.
>
> I see what you mean. The problem is that the JNI Weak Reference logging is only done for non-product builds. That means that if I want to guard the call to log_ref there I no longer have a one liner and need to go to #ifndef PRODUCT instead of just using the NOT_PRODUCT macro. When I do the unified logging changes the log_ref function will go away and even the non-product guard can go away. So, I think this can be cleaned up by that change.
>
> In the meantime I suggest that log_ref takes a parameter "doit" to make it clearer that it is the same as for the GCTraceTime. Are you ok with that?
Not that I want to encourage it, but it wouldn’t have been the first occurrence of complex code in a NOT_PRODUCT form rather than enclosed by #ifndef PRODUCT.
But I like what you did better than my suggestion.
>> ------------------------------------------------------------------------------
>> 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.
>
> You are right. I had some intermediate change where I needed to know the reference type, but as it is now this change is unnecessary. I reverted it.
Thanks.
>> ------------------------------------------------------------------------------
>> 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.
>
> I added the comment back. But I also left the comment in its new place where we set up the statistics. Since I've already missed reading this comment once I think it could be good to have it in both places where we treat Cleaners specially.
Thanks. That’s exactly what I was hoping for, but didn’t express clearly.
>> ------------------------------------------------------------------------------
>> 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.
>
> Good suggestion.
>
> Here's an updated webrev:
> http://cr.openjdk.java.net/~brutisso/8136991/webrev.05
>
> (Note that referenceType.hpp is unchanged even if webrev decides to include it.)
>
> And here's a diff compared to the last version:
> http://cr.openjdk.java.net/~brutisso/8136991/webrev.04-05.diff
Looks good.
More information about the hotspot-gc-dev
mailing list