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

[coleen.phillimore at oracle.com]

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).

Is this access ever a raw access?

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