RFR(S): 8153892: Handle unsafe access error directly in signal handler instead of going through a stub

[Mikael Vidstedt]

Yes, I asked myself the same thing when I started moving things around. 
It may be more appropriate to put it in sharedRuntime instead. Does 
anybody else have an opinion on where it should go?

Cheers,
Mikael

On 4/11/2016 2:03 AM, Thomas Stüfe wrote:
> Hi Mikael,
>
> just a question, should the new stubless functions not live someplace 
> else instead of in stubRoutines_<cpu> ? After all, they are not stub 
> routines anymore.
>
> Kind Regards, Thomas
>
> On Sat, Apr 9, 2016 at 12:33 AM, Mikael Vidstedt 
> <mikael.vidstedt at oracle.com <mailto:mikael.vidstedt at oracle.com>> wrote:
>
>
>     Please review:
>
>     Bug: https://bugs.openjdk.java.net/browse/JDK-8153892
>     Webrev:
>     http://cr.openjdk.java.net/~mikael/webrevs/8153892/webrev.01/hotspot/webrev/
>     <http://cr.openjdk.java.net/%7Emikael/webrevs/8153892/webrev.01/hotspot/webrev/>
>
>     * Note: this is patch 2 in a set of 3 all aiming to clean up and
>     unify the unsafe memory getters/setters, along with the handling
>     of unsafe access errors. The other two issues are:
>
>     https://bugs.openjdk.java.net/browse/JDK-8153890 - Handle unsafe
>     access error as an asynchronous exception
>     https://bugs.openjdk.java.net/browse/JDK-8150921 - Update Unsafe
>     getters/setters to use double-register variants
>
>
>     * Summary (copied from the bug description)
>
>
>     In certain cases, such as accessing a region of a memory mapped
>     file which has been truncated on unix-style operating systems, a
>     SIGBUS signal will be raised and the VM will process it in the
>     signal handler.
>
>     How the signal is processed differs depending on the operating
>     system and/or CPU architecture, with two major alternatives:
>
>     * "stubless"
>
>     Do the necessary thread state updates directly in the signal
>     handler, and modify the context so that the signal handler returns
>     to the place where the execution should continue
>
>     * Using a stub
>
>     Update the context so that when the signal handler returns the
>     thread will continue execution in a generated stub, which in turn
>     will call some native code in the VM to update the thread state
>     and figure out where execution should continue. The stub will then
>     jump to that new place.
>
>
>     It should be noted that the work of updating the thread state is
>     very small - it's setting a flag or two in the thread structure,
>     and figures out where the next instruction starts. It should also
>     be noted that the generated stubs today are broken, because they
>     do not preserve all the live registers over the call into the VM.
>     There are two ways to address this:
>
>     * Preserve all the necessary registers
>
>     This would mean implementing, in macro assembly, the necessary
>     logic for preserving all the live registers, including, but not
>     limited to, floating point registers, flag registers, etc. It
>     quickly becomes obvious that this platform specific and error prone.
>
>     * Leverage the fact that the operating system already does this as
>     part of the signal handling
>
>     Do the necessary work in the signal handler instead, removing the
>     need for the stub alltogether
>
>     As mentioned, on some platforms the latter model is already in
>     use. It is dramatically easier and all platforms should be updated
>     to do it the same way.
>
>
>     * Testing
>
>     Just as mentioned in the RFR for JDK-8153890, a new test was
>     developed to test this code path:
>
>     http://cr.openjdk.java.net/~mikael/webrevs/8150921/MappedTruncated.java
>     <http://cr.openjdk.java.net/%7Emikael/webrevs/8150921/MappedTruncated.java>
>
>     In fact, it was when running this test I found the register
>     preservation issue. JPRT also passes. Much like JDK-8153890 I
>     wanted to get some feedback on this before running additional tests.
>
>
>     Cheers,
>     Mikael
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20160411/ebcb0605/attachment.html>