RFR: 8144908: Remove apply_to_weak_ref_discovered_field override for UpdateRSOopClosure

Stefan Johansson stefan.johansson at oracle.com
Tue Dec 8 13:42:29 UTC 2015


Hi,

Please review this change for:
https://bugs.openjdk.java.net/browse/JDK-8144908

Webrev:
http://cr.openjdk.java.net/~sjohanss/8138888/8144908/hotspot.00/

Background:
When iterating objects with oop_iterate() there is a special case for 
InstanceRefKlass, if the closure overrides 
apply_to_weak_ref_discovered_field() to return true, the closure will be 
applied to the discovered field, even if the normal checks prevents it. 
This special treatment is needed in certain situations, but it is not 
obvious if it should be done when iterating the object. Currently only 
G1 closures override apply_to_weak_ref_discovered_field() and many of 
them seem to do it without any reason. My initial plan [1] was to remove 
all usage of this special casing but after discussions I realized it 
would be easier to see the effects if doing this one closure at a time.

Summary:
UpdateRSOopClosure is used to re-build the remembered sets after a G1 
full GC. This is done after reference discovery and enqueuing (to the 
pending list) has been completed, so all discovered references have 
their next-field set. Before the full GC is started all references 
discovered by the concurrent-mark reference processor is clear to allow 
them to be discovered during the full GC.

So at the point of applying the UpdateRSOopClosure, no references should 
have their discovered field set but still be active (next == null). So 
overriding apply_to_weak_ref_discovered_field to make sure the 
discovered field is handled doesn't have any effect. Either the 
discovered and next field are both set and thus gets handled the normal 
way, or the discovered field is not set and there is no reason to handle 
it at all.

Testing:
* RBT
* GC-test-suite run locally with small heap (to trigger full GC) and 
verification turned on.

Thanks,
Stefan

[1] https://bugs.openjdk.java.net/browse/JDK-8138888



More information about the hotspot-gc-dev mailing list