[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-hotspot-dev
Subject:    Re: RFR (S): 8191904: Refactor weak oops in ResolvedMethodTable to use the Access API
From:       Erik_Österlund <erik.osterlund () oracle ! com>
Date:       2017-11-28 14:12:43
Message-ID: 5A1D6EDB.8050709 () oracle ! com
[Download RAW message or body]

Hi Thomas,

On 2017-11-28 14:12, Thomas Schatzl wrote:
> Hi,
>
> On Tue, 2017-11-28 at 13:26 +0100, Erik =C3=96sterlund wrote:
>> Hi Coleen,
>>
>> On 2017-11-27 19:33, coleen.phillimore@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.

Okay, will sort out.

Thanks,
/Erik

> Thanks,
>    Thomas
>

[prev in list] [next in list] [prev in thread] [next in thread]