[aarch64-port-dev ] [Roland Westrelin] Re: Aarch64 port for ZGC, so far

Per Liden per.liden at oracle.com
Wed May 1 19:05:33 UTC 2019

Hi Stuart,

On 04/30/2019 07:36 PM, Stuart Monteith wrote:
> I've made a patchset with multi-mapping for aarch64, which is
> literally a copy from x86. It doesn't require the 64bit literal
> addresses patch, as the bits all fit within 48 bits:
>      http://cr.openjdk.java.net/~smonteith/zgc-mm/20190430/
> There is also an updated patchset for the tagged pointers, with a fix
> for the JNI "Critical" functions to mask out the tags:
> http://cr.openjdk.java.net/~smonteith/zgc/20190430/
> These patchsets apply to the tip today, so they take into account the
> new 4/8/16TB heap limits Per introduced.
> I'm currently regression testing, and benchmarking with/without
> tagging. With tags there are 64-bit literals that ought to have a
> negative effect on performance, and with multimapping there might be
> some impact from the TLB. Having said that, the impact is expected to
> be small on the TLB as Per explained.
> Once I've settled on an approach, I'll post RFRS - I'd really like for
> ZGC for Aarch64 to get into OpenJDK for JDK 13.

Sounds good. Just a heads up that there are two things that I think we 
want merged before the aarch64 port goes in. The first is JEP 351 
(uncommit). With multi-mapping, you'll get uncommit support for aarch64 
for free. With tagged pointers, some additional work will be needed in 
ZPhysicalMemoryBacking for aarch64. The second thing is Nils' work to 
improve/simplify the C2 barriers. That will affect ZGC's ad-file, but 
there shouldn't be too much work to adapt to that.

My best guess at this time is that both of these things will be merged 
in the near future (JEP 351 will hopefully be targeted for 13 by end of 

Btw, if you go with multi-mapping, then we'll just move the copied files 
from os_cpu/linux_x86 to os/linux. And you can of course always go with 
multi-mapping first, and switch to using tagging at some point later (or 
vice versa for that matter).


> BR,
>     Stuart
> On Mon, 15 Apr 2019 at 17:28, Stuart Monteith
> <stuart.monteith at linaro.org> wrote:
>> Thanks Per, I've not encountered any issues so far with that. With the
>> fix to JNI, I expect ZGC should be functioning properly now... until
>> the next edge-case when it is not.
>> This is my current set of patches:
>>     http://cr.openjdk.java.net/~smonteith/zgc/20190415/
>> It was built on tip from this morning. Meanwhile, I'll work on a patch
>> for multi-map ZGC for comparison.
>> BR,
>>    Stuart
>> On Mon, 15 Apr 2019 at 16:33, Per Liden <per.liden at oracle.com> wrote:
>>> On 04/15/2019 05:25 PM, Andrew Haley wrote:
>>>> On 4/15/19 3:57 PM, Stuart Monteith wrote:
>>>>>      If I understand this correctly, siginfo_t would contain the
>>>>> faulting address with the tag wiped. The ucontext would still contain
>>>>> the full 64-bit registers, unmolested. I've asked internally, but that
>>>>> is how I've interpreted it.
>>>> That sounds sensible.
>>> Also note that depending on what this oop is used for in the signal
>>> handler, you might not need the tag bits (they typically are only useful
>>> for ZGC). But if you really do need them, you can call
>>> ZAddress::good(oop) to slap the bits on again.
>>> cheers,
>>> Per

More information about the zgc-dev mailing list