RFR: 8208582: Introduce native oop barriers in C1 for OopHandle
Erik Österlund
erik.osterlund at oracle.com
Wed Aug 1 13:37:23 UTC 2018
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
>
More information about the hotspot-compiler-dev
mailing list