[aarch64-port-dev ] Aarch64 port for ZGC, so far

[Per Liden]

Ah, yes! I had forgot about that little feature, that's even better of 
course ;)

/Per

On 2018-11-30 17:31, Stuart Monteith wrote:
> Thanks.  zBitField has a "ValueShift" template parameter, so I can
> just do this instead:
> 
>    typedef ZBitField<uint64_t, uintptr_t, 2,  62, 3> field_object_address;
> 
> And that will preserve the top bits.
> 
> On Fri, 30 Nov 2018 at 15:12, Per Liden <per.liden at oracle.com> wrote:
>>
>> Hi,
>>
>> On 11/30/18 1:22 PM, Stuart Monteith wrote:
>>> Hello,
>>>        You're right, I was halfway through hedging my bets. One thing
>>> that concerns me is the longevity of a solution that uses the ignored
>>> bits. I recently moved the ZGC's coloured bits to the top 4 bits to
>>> avoid the up and coming Memory Tagging Extensions (MTE) in ARMv8.5 -
>>> they currently use bits 56 to 59, and so I'd be clear if I used bits
>>> 60 to 63. See: https://developer.arm.com/docs/ddi0596/a/a64-shared-pseudocode-functions/aarch64-functions-pseudocode#impl-shared.AddressWithAllocationTag.2_2
>>> I've come across an issue where zMarkStackEntry is assuming the top
>>> two bits of an address aren't significant, whereas they are. This
>>> results in references losing some of their colour.
>>>
>>> As I see it I either ignore MTE for now, take it into account and
>>> alter zMarkStackEntry to drop some bits between, say, bits 52 to 54,
>>> or to somehow have aarch64 able to use multimapping or VA-masking.
>>>
>>> But in conclusion, I won't leave that code as it is.
>>
>> Ok, I see. The zMarkStackEntry issue should be fixable by doing
>> something like:
>>
>>     field_object_address::encode(object_address >> 3)
>>
>> and:
>>
>>     field_object_address::decode(_entry) << 3;
>>
>> in the relevant places, right?
>>
>> cheers,
>> Per
>>
>>>
>>> Thanks,
>>>       Stuart
>>>
>>>
>>> On Fri, 30 Nov 2018 at 08:06, Per Liden <per.liden at oracle.com> wrote:
>>>>
>>>> Hi Stuart,
>>>>
>>>> On 11/23/18 12:46 PM, Stuart Monteith wrote:
>>>>> Hello,
>>>>>      I thought I'd update where I am with ZGC. The C1 code seems to be
>>>>> mostly working. I had an issue where ZMarkStack was stripping off the
>>>>> top two bits of the 64-bit addresses, which is where I've put the
>>>>> thread colours to avoid tags in MTE.
>>>>>     I've added some support for C2 to the ZGC code. There are some
>>>>> issues, however, with the graph.
>>>>>
>>>>> As before the 64-bit Literal oops support patch is needed:
>>>>>       http://cr.openjdk.java.net/~smonteith/oop64/webrev-20181002/
>>>>>
>>>>> The patchset is here:
>>>>>          http://cr.openjdk.java.net/~smonteith/zgc/webrev-20181121/
>>>>
>>>> Thanks for the update. Just did a quick scan over the patch, and noticed
>>>> a couple of things.
>>>>
>>>> src/hotspot/share/gc/shared/gcArguments.cpp
>>>> -------------------------------------------
>>>> The check added here seems to belong in zArguments.cpp. We might even
>>>> want to introducing a zArguments_<arch>.cpp in the future, but
>>>> zArguments.cpp works for now.
>>>>
>>>>
>>>> src/hotspot/os_cpu/linux_aarch64/gc/z/zBackingFile_linux_aarch64.cpp
>>>> src/hotspot/os_cpu/linux_aarch64/gc/z/zBackingFile_linux_aarch64.hpp
>>>> src/hotspot/os_cpu/linux_aarch64/gc/z/zBackingPath_linux_aarch64.cpp
>>>> src/hotspot/os_cpu/linux_aarch64/gc/z/zBackingPath_linux_aarch64.hpp
>>>> --------------------------------------------------------------------
>>>> With VA-masking enabled, the functionality provided by the above files
>>>> should not be needed since you can just map anonymous memory.
>>>>
>>>> cheers,
>>>> Per
>>>>
>>>>>
>>>>> To run with ZGC enabled, you'll need to pass:
>>>>>        -XX:+UnlockExperimentalVMOptions
>>>>>        -XX:+UseZGC
>>>>>
>>>>> I've included a test case here:
>>>>>       http://cr.openjdk.java.net/~smonteith/zgc/C2Examples/
>>>>>
>>>>> Which can be executed with or without "-XX:+UseBarriersForVolatile" to
>>>>> reproduce two different errors.
>>>>>
>>>>> With that option I see:
>>>>>       #  Internal Error
>>>>> (/home/stuart/jdk/src/hotspot/share/opto/matcher.cpp:1663), pid=16859,
>>>>> tid=17048
>>>>>      #  assert(C->node_arena()->contains(s->_leaf) ||
>>>>> !has_new_node(s->_leaf)) failed: duplicating node that's already been
>>>>> matched
>>>>>
>>>>> and without I see:
>>>>>     #  Internal Error
>>>>> (/home/stuart/jdk/src/hotspot/cpu/aarch64/aarch64.ad:1438), pid=3436,
>>>>> tid=3503
>>>>>     #  assert(ldst->trailing_membar() != __null) failed: expected trailing membar
>>>>>
>>>>> This is due to a combination of the graph generated in
>>>>> ZBarrierSetC2::make_cas_loadbarrier and apparently the memory barrier
>>>>> handling in aarch64.ad that Roland recently changed in "8209420: Track
>>>>> membars for volatile accesses so they can be properly optimized". This
>>>>> is easily triggered in the C2Example.java file I've linked to above,
>>>>> where calls to Unsafe.compareAndSwapObject provoke the issue.
>>>>>
>>>>> I'm trying to unpick the problems with the graph - I've uploaded the
>>>>> replay, hs_err and ideal graph xml files of runs with and without
>>>>> +UseBarriersForVolatile, in case someone could provide some insight.
>>>>>
>>>>> BR,
>>>>>       Stuart
>>>>>