RFR (S): 8191894: Refactor weak references in JvmtiTagHashmap to use the Access API

[coleen.phillimore at oracle.com]

On 11/28/17 7:37 AM, Erik Österlund wrote:
> Hi Coleen,
>
> That's it, yes. Hope I answered the question.

Yes, thanks.
Coleen

>
> Thanks,
> /Erik
>
> On 2017-11-27 19:28, coleen.phillimore at oracle.com wrote:
>>
>>
>> On 11/27/17 1:21 PM, coleen.phillimore at oracle.com wrote:
>>> http://cr.openjdk.java.net/~eosterlund/8191894/webrev.00/src/hotspot/share/prims/jvmtiTagMap.cpp.udiff.html 
>>>
>>>
>>> + return RootAccess<ON_PHANTOM_OOP_REF | 
>>> AS_NO_KEEPALIVE>::oop_load(object_addr());
>>>
>>
>> Sorry I have my Access API dimensions mixed up.  RootAccess is 
>> IN_ROOT not ON_ROOT (and not concurrent).
>>
>> Coleen
>>>
>>> Why is this not access ON_ROOT{_CONCURRENT} ?  The thing holding the 
>>> object that you are peeking at is not in the Java Heap?
>>>
>>> thanks,
>>> Coleen
>>>
>>> On 11/27/17 6:28 AM, Erik Österlund wrote:
>>>> Hi,
>>>>
>>>> The JVMTI tag hashmap has weak oop references that are handled 
>>>> using raw oop accesses and a G1-specific SATB enqueue call when 
>>>> leaking out objects from the tag map, requiring them to be marked 
>>>> as live by G1.
>>>>
>>>> This should now be refactored to use the Access API to annotate 
>>>> that these are ON_PHANTOM_OOP_REF, and refactor the raw oop loads 
>>>> to use ON_PHANTOM_OOP_REF | AS_NO_KEEPALIVE.
>>>>
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~eosterlund/8191894/webrev.00/
>>>>
>>>> Bug:
>>>> https://bugs.openjdk.java.net/browse/JDK-8191894
>>>>
>>>> Thanks,
>>>> /Erik
>>>
>>
>