RFR: 8208582: Introduce native oop barriers in C1 for OopHandle

[Erik Österlund]

Hi Coleen,

Thank you for the review.

On 2018-08-01 13:21, coleen.phillimore at oracle.com wrote:
>
> Erik, pattern matching with the macroAssembler the C1 code looks good.
>
> http://cr.openjdk.java.net/~eosterlund/8208582/webrev.00/src/hotspot/share/c1/c1_LIRGenerator.cpp.udiff.html 
>
>
> Did you pass BasicType to access_load rather than hard-code T_OBJECT 
> to support shenandoah? (same question for the MacroAssembler version).

No I did it for consistency with the other access_load_at API. 
Shenandoah will not need special support for off-heap primitives; only 
on-heap primitives.

> Is this access ever a raw access?

Not at the moment, but who knows what the future might hold. I support 
it for consistency to reduce surprises for future users of the API, as 
it is trivial enough to do so.

Thanks,
/Erik

> Thanks,
> Coleen
>
> On 7/31/18 11:44 AM, Erik Osterlund wrote:
>> +hotspot-dev by popular demand
>>
>>> On 31 Jul 2018, at 17:35, Erik Österlund <erik.osterlund at oracle.com> 
>>> wrote:
>>>
>>> Hi,
>>>
>>> There is currently no way of doing IN_NATIVE accesses in C1 using 
>>> its access API. These are required to properly access OopHandle, 
>>> used to access the Java class mirrors (because they will now start 
>>> requiring load barriers). In order to support concurrent class 
>>> unloading in ZGC, this support must be added.
>>>
>>> This webrev adds C1 support for this:
>>> http://cr.openjdk.java.net/~eosterlund/8208582/webrev.00/
>>> Bug URL:
>>> https://bugs.openjdk.java.net/browse/JDK-8208582
>>>
>>> Thanks,
>>> /Erik
>