RFR (S): 8191904: Refactor weak oops in ResolvedMethodTable to use the Access API

[Erik Österlund]

Hi Coleen,

On 2017-11-27 19:33, coleen.phillimore at oracle.com wrote:
> This looks good. 

Thank you for the review.

> I think we should make the literal() function in this hashtable a pure 
> virtual function and ShouldNotReachHere to not allow it for these 
> classes derived from oop.

That might be a good idea indeed.

> BTW, should we expect a StringTable and ProtectionDomainEntryTable 
> change as well?  The latter is missing the SATB barrier at the moment.

StringTable changes are coming up indeed. About the 
ProtectionDomainEntryTable, I have not prepared a patch yet. From 
looking at it briefly, it did look like we were only ever "peeking" at 
the value and never exposing it. So should probably just use 
RootAccess<ON_PHANTOM_OOP_REF | AS_NO_KEEPALIVE>::oop_load all over. 
This will not translate to any actual barrier on any collector, but is 
probably a good abstraction to have anyway. If you want this, I will 
prepare a patch for it.

Thanks,
/Erik

> Coleen
>
> On 11/27/17 10:33 AM, Erik Österlund wrote:
>> Hi,
>>
>> The ResolvedMethodTable has weak oop references in it. Currently it 
>> uses explicit SATB enqueueing for G1 to make the weak semantics work.
>>
>> This should be refactored to use the Access API instead. The previous 
>> raw loads should be ON_PHANTOM_OOP | AS_NO_KEEPALIVE and the loads 
>> followed by explicit G1 SATB enqueueing should be ON_PHANTOM_OOP.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~eosterlund/8191904/webrev.00/
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8191904
>>
>> Thanks,
>> /Erik
>