RFR(s): 8076185: Provide SafeFetchX implementation for zero

[Thomas Stüfe]

On Tue, Mar 31, 2015 at 11:45 AM, Severin Gehwolf <sgehwolf at redhat.com>
wrote:

> Hi,
>
> On Tue, 2015-03-31 at 11:08 +0200, Thomas Stüfe wrote
>
>
> >         > We also should accept that my SafeFetch implementation will
> >         be slower
> >         > than the standard one using inline assembly, because
> >         setjmp() does a
> >         > lot of stores. As far as I can see now, we do not use
> >         SafeFetch
> >         > extensivly anywhere, so this should be ok, but something to
> >         keep in
> >         > mind.
> >
> >         This is expected. The only use of SafeFetch I'm aware is in
> >         src/share/vm/runtime/objectMonitor.cpp and the error handler.
> >         Speaking
> >         of which:
> >
> >         $ java -XX:+UnlockDiagnosticVMOptions -Xmx100M
> >         -XX:ErrorHandlerTest=14 -XX:+TestSafeFetchInErrorHandler
> >         -version
> >
> >         Does not yet work as expected. But that's a separate issue.
> >
> >
> >
> > That is ok.
> >
> >
> > For -XX:+TestSafeFetchInErrorHandler to work, we would need to handle
> > SafeFetch faults in the secondary signal handlers too (see
> > vmError_<os>.cpp). That could be easily added but we would leave POSIX
> > territory. Using longjmp() is not guaranteed to work from nested
> > signal handlers ("However, if longjmp() is invoked from a nested
> > signal handler (that is, from a function invoked as a result of a
> > signal raised during the handling of another signal), the behaviour is
> > undefined.").
> >
> >
> > I think that use case is not that important for zero.
>
> I agree. Should we make note of this in JDK-8074552?
>
>
I added a note to JDK-8074552.

..Thomas


> Thanks,
> Severin
>
>
>