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

[Severin Gehwolf]

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?

Thanks,
Severin