On Wed, 25 Nov 2020 08:30:46 GMT, Vladimir Ivanov <vliva...@openjdk.org> wrote:
>> JDK-8188055 added the function Reference.refersTo. For performance, the
>> supporting native methods Reference.refersTo0 and PhantomReference.refersTo0
>> should be intrinsified by C2.
>>
>> Initial patch was prepared by @fisk.
>>
>> Tested hs-tier1-4. Added new compiler tests to test intrinsics.
>>
>> Ran new test with Shenandoah. Found only one issue. As result I disable
>> PhantomReference::refersTo intrinsic for COOP+ Shenandoah combination.
>> Someone from Shenandoah team have to test changes if that is enough.
>
> src/hotspot/cpu/x86/gc/z/z_x86_64.ad line 123:
>
>> 121:
>> 122: ins_encode %{
>> 123: if (barrier_data() != 0) { // barrier could be elided by
>> ZBarrierSetC2::analyze_dominating_barriers()
>
> Maybe keep a bit reserved for `ZLoadBarrierElided` to just map it to `0`? The
> former is preferred because it keeps the info that there was a barrier data
> attached in the first place.
The information that there was a barrier attached, is implicit in the
ins_encode block due to it being run at all. In other words, since we matched
the mach node to our ZGC access instead of a normal access, we already know
that there was barrier data attached, and that we no longer have such barrier
data.
-------------
PR: https://git.openjdk.java.net/jdk/pull/1425
