Re: [16]RFR(S):8249092:InternalError: a fault occurred in a recent unsafe memory access operation in compiled Java code

[Wang Zhuo(Zhuoren)]

OK, thanks David.
>     The use of GuardUnsafeAccess with the CAS primitives on some platforms
>     can result in an infinite loop as the mechanism cannot be applied to
>     arbitrary code sequences.
Do you have a test for this? If the patch for JDK-8246051 indeed causes such problem. I am considering to do reverting or some other modifications.

Regards,
Zhuoren



------------------------------------------------------------------
From:David Holmes <david.holmes at oracle.com>
Sent At:2020 Sep. 3 (Thu.) 12:12
To:Sandler <zhuoren.wz at alibaba-inc.com>; Patric Hedlin <patric.hedlin at oracle.com>; aarch64-port-dev <aarch64-port-dev at openjdk.java.net>; hotspot-runtime-dev <hotspot-runtime-dev at openjdk.java.net>
Cc:rahul.v.raghavan <rahul.v.raghavan at oracle.com>
Subject:Re: [16]RFR(S):8249092:InternalError: a fault occurred in a recent unsafe memory access operation in compiled Java code

On 3/09/2020 1:49 pm, Wang Zhuo(Zhuoren) wrote:
> David, Thank you very much for the explanation.
> The original crash indeed happened in a third party code using Unsafe to 
> handle unaligned data.
> So you mean that it is the third party code's bug, we should not fix it 
> in JVM, right?

Right. Unsafe is not a supported API and is by definition unsafe. If you 
use it and it crashes then you need to change your code.

Cheers,
David
-----

> Regards,
> Zhuoren
> 
>     ------------------------------------------------------------------
>     From:David Holmes <david.holmes at oracle.com>
>     Sent At:2020 Sep. 3 (Thu.) 10:58
>     To:Sandler <zhuoren.wz at alibaba-inc.com>; Patric Hedlin
>     <patric.hedlin at oracle.com>; aarch64-port-dev
>     <aarch64-port-dev at openjdk.java.net>; hotspot-runtime-dev
>     <hotspot-runtime-dev at openjdk.java.net>
>     Cc:rahul.v.raghavan <rahul.v.raghavan at oracle.com>
>     Subject:Re: [16]RFR(S):8249092:InternalError: a fault occurred in a
>     recent unsafe memory access operation in compiled Java code
> 
>     Hi,
> 
>     On 3/09/2020 12:07 pm, Wang Zhuo(Zhuoren) wrote:
>      > Hi Patric,
>      > The original problem(https://bugs.openjdk.java.net/browse/JDK-8246051)
>      > is architecture specific. When running TestUnsafeUnalignedSwap.java on
>      > aarch64 platforms, JVM crashes without the fix because aarch64 does not
>      > support unaligned compare_and_swap. On X86 platforms the crash cannot be
>      > reproduced because X86 support unaligned compare_and_swap.
> 
>     Patric is asking about the original situation where an unaligned CAS was
> 
>     performed, which motivated the change made by JDK-8246051.
> 
>     The GuardUnsafeAccess mechanism (or more specifically the signal
>     handling tricks underneath it) was not intended for general use, but was
> 
>     specifically created to deal with the case of page faults related to
>     mapped ByteBuffers where we wanted application code using JDK exported
>     APIs to get an InternalError when they did the wrong thing with their
>     mapped files, instead of crashing. No part of the JDK should be calling
>     Unsafe.compareAndSwap* with unaligned data - if it does that is a bug.
>     If third-party code is using Unsafe directly then that is their problem
>     and we do not try to make things easier for them.
> 
>     The use of GuardUnsafeAccess with the CAS primitives on some platforms
>     can result in an infinite loop as the mechanism cannot be applied to
>     arbitrary code sequences. Somewhat ironically Aarch64 is one platform
>     that can suffer from this.
> 
>     Cheers,
>     David
>     -----
> 
>      >
>      > Regards,
>      > Zhuoren
>      >
>      >     ------------------------------------------------------------------
>      >     From:Patric Hedlin <patric.hedlin at oracle.com>
>      >     Sent At:2020 Sep. 2 (Wed.) 20:22
>      >     To:Sandler <zhuoren.wz at alibaba-inc.com>; aarch64-port-dev
>      >     <aarch64-port-dev at openjdk.java.net>; hotspot-runtime-dev
>      >     <hotspot-runtime-dev at openjdk.java.net>
>      >     Cc:david.holmes <david.holmes at oracle.com>; rahul.v.raghavan
>      >     <rahul.v.raghavan at oracle.com>
>      >     Subject:Re: [16]RFR(S):8249092:InternalError: a fault occurred in a
>      >     recent unsafe memory access operation in compiled Java code
>      >
>      >     Hi Zhuoren,
>      >
>      >     I don't actually know what behaviour to expect from the Unsafe
>      >     atomics in this test-case but perhaps you could re-cap the original
>      >     problem (addressed in JDK-8246051) since it seems to raise some
>      >     questions. Did you have an example (real code) where this behaviour
>      >     is essential?
>      >
>      >     Best regards,
>      >     Patric Hedlin
>      >
>      >     (Including hotspot-runtime-dev at openjdk.java.net)
>      >
>      >
>      >     On 2020-09-01 07:35, Wang Zhuo(Zhuoren) wrote:
>      >     Hi, this is a fix for a test case.
>      >     In -Xcomp mode, compiler/unsafe/TestUnsafeUnalignedSwap.java will
>      >     fail because the catch misses the error due to async exception.
>      >     This patch uses a loop to make sure the error can be caught. Also
>      >     -Xcomp is added in test.
>      >     BUG: https://bugs.openjdk.java.net/browse/JDK-8249092
>      >     Patch: http://cr.openjdk.java.net/~wzhuo/8249092/webrev.00/
>      >
>      >
>      >     Regards,
>      >     Zhuoren
>      >
>      > 
>