RFR: 8138888: Remove ExtendedOopClosure::apply_to_weak_ref_discovered_field

[Stefan Johansson]

Thanks Kim for looking at this,

On 2017-04-28 20:34, Kim Barrett wrote:
>> On Apr 25, 2017, at 7:41 AM, Stefan Johansson <stefan.johansson at oracle.com> wrote:
>>
>> Hi,
>>
>> Please review this change for:
>> https://bugs.openjdk.java.net/browse/JDK-8138888
>>
>> Webrev:
>> http://cr.openjdk.java.net/~sjohanss/8138888/hotspot.00/
>>
>> Summary:
>> This change builds upon 8138737 which is currently out for review. With that change we now have a more generic mechanism to add special handling for closures when visiting InstanceRefKlasses. With this mechanism we can remove ExtendedOopClosure::apply_to_weak_ref_discovered_field and replace it with a new ReferenceIterationMode which provides the same functionality.
>>
>> The RFE in JBS also proposes to remove the functionality of apply_to_weak_ref_discovered_field, but to do this some more analysis is needed. Doing this changes is a step in the direction of making it easier to remove the need for this functionality in future changes.
>>
>> Testing:
>> * JPRT
>> * RBT hs-tier 2+3
>>
>> Thanks,
>> Stefan
> ------------------------------------------------------------------------------
> 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.

Thanks,
Stefan
> ------------------------------------------------------------------------------
>