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

[Thomas Schatzl]

Hi,

On Tue, 2017-11-28 at 13:26 +0100, Erik Österlund wrote:
> 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.

If I understand its use correctly (still wrapping my head around this),
since some of your other changes also add this abstraction "where it is
not needed" it would be nice to have.

Thanks,
  Thomas