RFR: 8138888: Remove ExtendedOopClosure::apply_to_weak_ref_discovered_field

Kim Barrett kim.barrett at oracle.com
Tue May 2 20:41:28 UTC 2017


> On May 2, 2017, at 11:12 AM, Stefan Johansson <stefan.johansson at oracle.com> wrote:
> 
> Thanks Kim for looking at this,
> 
> On 2017-04-28 20:34, Kim Barrett wrote:
>> src/share/vm/oops/instanceRefKlass.inline.hpp
>> 
>>  114 void InstanceRefKlass::oop_oop_iterate_discovered_and_discovery(oop obj, ReferenceType type, OopClosureType* closure, Contains& contains) {
>>  115   // Explicitly apply closure to the discovered field.
>>  116   do_discovered<nv, T>(obj, closure, contains);
>>  117   // Then do normal reference processing with discovery.
>>  118   oop_oop_iterate_discovery<nv, T>(obj, type, closure, contains);
>>  119 }
>> 
>> This will apply the closure to the discovered field, and then
>> (conditionally) log the processing of the reference (at the start of
>> oop_oop_iterate_discovery).
>> 
>> Also, oop_oop_iterate_fields doesn't have a corresponding log message
>> at the start.
>> 
>> Maybe the thing to do is to have the on-entry logging in
>> oop_oop_iterate_ref_processing_specialized, with the message
>> specialized by the iteration mode.
> I agree, the logging here could be a bit more unified. What do you think about using trace_reference_gc for all of them? Like this:
> Webrev: http://cr.openjdk.java.net/~sjohanss/XXXXXXX/hotspot.00/
> 
> I would like to push that as a separate RFE though.

I like this additional change.  If it’s going to be a separate RFE then I’d prefer
it went first, so there isn’t a (hopefully temporary) stage where things are kind
of wrong.  I realize that’s more work, so I won’t insist.




More information about the hotspot-gc-dev mailing list