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

[Stuart Monteith]

Hello,
   At some point earlier on another thread the connection is being
closed, hence the XIOError here. This error is being caused because
the libx11 library is writing some image data to its socket with
"writev(int fd, const struct iovec *iov, int iovcnt);" returning an
error. The errno associated with that is EFAULT - which means the
kernel was being passed a bad address.
The reason running with AWT is exiting is that tagged addresses are
regarded as bad by the kernel, and we are passing an address derived
from a Java byte array that is on the heap. The AWT JNI code calls
jni_GetPrimitiveArrayCritical to get that address.
Patching that one JNI call is sufficient to start IDEA, and any of the
jfc demos. You can also try "-XX:+CheckJNICalls", which works as it
forces JNI to always copy arrays that are passed to/from JNI to a
temporary array that does not have a tagged address.

If I pursue the tagged addresses, I have to make sure that tagged
addresses are masked in all of the correct areas. As well as this part
of JNI I must consider the likes of the Unsafe API, and, a bit
unrelated, I know of another instance where I get an Exception
"sun.jvm.hotspot.debugger.UnmappedAddressException" in the
serviceability/sa tests.

An alternative is to reproduce the multimapping that is on x86, where
all addresses are real. This has the advantage that when the Memory
Tagging Extensions (MTE) in AArch64 are implemented, they won't
encroach on the ZGC coloured bits, and vice versa. Realistically if we
are ever to use MTE, ZGC may prevent that from happening.

I believe the only reason we should continue with using the aarch64
TBI tagged addresses is if it confers a good performance advantage
over multimapping. My plan is to patch JNI for now in my ZGC patch,
and then work on a new patch but with x86 style multimapping, which
ought to be a straight copy. As I understand it, only one bit of
colour is significant in ZGC at any given time, so the TLB impact
might not be so bad for the majority of the time, but we'll need to
check that.

The 64-bit literal addresses isn't strictly speaking at that point.
Per's patch for expanding maximum heap size to 16TB will still fit in
48-bits (with not bits spare), and so it would only be necessary for
52-bit VA support on aarch64, or if we ever feel the need to offer
32TB  VA.

BR,
   Stuart



On Fri, 15 Mar 2019 at 18:52, Andrew Haley <aph at redhat.com> wrote:
>
> On 3/14/19 5:26 PM, Stuart Monteith wrote:
> > The patches are here:
> >
> > http://cr.openjdk.java.net/~smonteith/zgc/20190314/
> >
> > I'm doing some more testing and then move onto RFRs.
>
> After https://www.jetbrains.com/idea/ starts up, I get an exit in the "AWT-XAWT" thread:
>
> #0  0x000003ff7eea77d8 in exit () from /lib64/libc.so.6
> #1  0x000003fd40a14bac in _XIOError () from /lib64/libX11.so.6
> #2  0x000003fd40a125ec in _XEventsQueued () from /lib64/libX11.so.6
> #3  0x000003fd40a0452c in XEventsQueued () from /lib64/libX11.so.6
> #4  0x000003fd40bb773c in Java_sun_awt_X11_XlibWrapper_XEventsQueued (env=0x3fcf032bc10,
>     clazz=0x3fd4146e0f0, display=4384894979008, mode=1)
>     at /local/jdk-zgc-new/src/java.desktop/unix/native/libawt_xawt/xawt/XlibWrapper.c:804
>
>  0x000003fd4146e1b0: 0x000003fd4146e250 #2 method sun.awt.X11.XToolkit.run(Z)V @ 63
>                                         - 8 locals 7 max stack
>
> If I had to guess I'd say something was leaking. The nice thing is, though,
> that the failure is entirely repeatable.
>
> --
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671