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

[Per Liden]

Hi Stuart,

On 12/3/18 7:00 PM, Stuart Monteith wrote:
> Hi Per,
>     I've moved the logic to zArguments for enabling Use64BitLiteralOops
> - it sits much nicer there, thanks.
> 
> I've removed the zBacking* code - but just one question. Am I correct
> in thinking that ZPhysicalMemoryBacking::try_expand(size_t, size_t)
> can simply unconditionally return the new_capacity? There is no
> backing file that requires extending, and the pages will have already
> been allocated in the address space, albeit not actually physically.

That's correct, just have it return new_capacity. Also, you don't need a 
ZMemoryManager to keep track of free memory segments, since that job is 
essentially handled by the kernel in this setup. So alloc() can look 
like this:

ZPhysicalMemory ZPhysicalMemoryBacking::alloc(size_t size) {
   assert(is_aligned(size, _granule_size), "Invalid size");
   return ZPhysicalMemory(size);
}

And free() becomes a no-op, but it might be nice to have an assert there 
(like we had in the Sparc version).

void ZPhysicalMemoryBacking::free(ZPhysicalMemory pmem) {
   assert(pmem.nsegments() == 1, "Invalid number of segments");
}

And in map(), you can just use mmap(..MAP_HUGETLB...) if 
ZLargePages::is_explicit() is true, or map without MAP_HUGETLB and then 
call madvise(...MADV_HUGEPAGE...) if ZLargePages::is_transparent() is true.

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