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

machunhui (C) machunhui2 at huawei.com
Mon May 6 02:24:09 UTC 2019


Hi,stuart:
When trying zgc patch on aarch64 we also met some crashes when running jtreg, and we found that the reason might be in tagged pointer:
When deleting the field instruction_size in class NativeMovConstReg, the default value of instruction_size is inherited from NativeInstruction, whose value is not appropriate and it may cause some code cache pollution.

Undeleting and assigning an initial value to instruction_size  *or*  the following change both work fine for me:

diff --git a/src/hotspot/cpu/aarch64/nativeInst_aarch64.cpp b/src/hotspot/cpu/aarch64/nativeInst_aarch64.cpp
index 7bf5fa2..7518811 100644
--- a/src/hotspot/cpu/aarch64/nativeInst_aarch64.cpp
+++ b/src/hotspot/cpu/aarch64/nativeInst_aarch64.cpp
@@ -271,7 +271,7 @@ void NativeMovConstReg::set_data(intptr_t x) {
   } else {
     // Store x into the instruction stream.
     MacroAssembler::pd_patch_instruction(instruction_address(), (address)x);
-    ICache::invalidate_range(instruction_address(), instruction_size);
+    ICache::invalidate_range(instruction_address(), get_instruction_size());
   }

Thanks.

--------------------------------------------------
马春辉 Ma Chunhui
Mail: machunhui2 at huawei.com
2012实验室-语言虚拟机实验室
2012 Laboratories-Language VM Lab,2012Labs


-----邮件原件-----
发件人: aarch64-port-dev [mailto:aarch64-port-dev-bounces at openjdk.java.net] 代表 Stuart Monteith
发送时间: 2019年5月4日 0:07
收件人: Per Liden <per.liden at oracle.com>
抄送: zgc-dev at openjdk.java.net; aarch64-port-dev <aarch64-port-dev at openjdk.java.net>
主题: Re: [aarch64-port-dev ] [Roland Westrelin] Re: Aarch64 port for ZGC, so far

Thanks for the heads up Per. The JTREG testing has shown some interesting errors with ZGC - I'm not sure whether all of these are to do with tagging, but I'll be comparing them against ZGC without tagging.

I'm very conscious of the June 13th deadline. Would a JEP be appropriate for ZGC on aarch64? I'm not sure of the precedent, as I'd expect it to just be "same as on x86".

One item to follow is, of course, class unloading.

BR,
  Stuart

On Wed, 1 May 2019 at 20:05, Per Liden <per.liden at oracle.com> wrote:
>
> 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 tomorrow).
>
> 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).
>
> cheers,
> Per
>
> >
> > 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