Protecting the JVM from segfaults

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Wed Apr 7 11:06:01 UTC 2021


Please disregard JEP 191. This is a "legacy" JEP which has been written 
when Panama started out (thanks to John and Charlie!).

More recent works on the topic are:

* Foreign Memory Access API: JEP 370, JEP 383, JEP 393
* Foreign Linker API: JEP 389

The way the Foreign Memory Access API protects against SEGV is not by 
wrapping them as regular Java exception (I'm not sure how that would be 
possible in the general case), but to disallow access which occur 
outside the bounds of a memory segment, or after a memory segment has 
been _closed_.

We do have some synergy with the GC and the concept of safepoint, in 
order to make sure that the "cannot access after closed" guarantee is 
not only valid for segments that are accessed from a single thread, but 
also for segments accessed by multiple threads at once (at the cost of a 
more expensive close() operation).

In other words, the Foreign Memory Access API gives you optimal memory 
access performances (similar to what you'd get with Unsafe) with extra 
safety in both the confined and the shared case.

Of course there are times where  a program just wants to defererence a 
raw pointer (MemoryAddress, in the API lingo) obtained from native code; 
in such cases you can still convert that address to a memory segment and 
dereference it - but that conversion is a privileged operation, which 
requires an extra command line flag to add the caller module to the list 
of modules that are allowed raw native access.

Maurizio

On 07/04/2021 11:33, Michael Böckling wrote:
> In JEP 191, it says:
>
>
> "Optionally, this JEP will build additional support for the above features
> via: JVM-level awareness of FFI downcalls. This could include: JIT
> optimization of those calls, JVM/GC-level awareness of native memory,
> protection against illegal native memory accesses (SEGV faults), and
> mechanisms to opt out of JNI safeguards known to be unnecessary in specific
> cases (safepoint boundaries, blocking call guarantees, object lifecycle
> management, etc.)."
>
>
> Are there any plans to implement "protection against illegal native memory
> accesses (SEGV faults)"somehow? I cannot imagine how that would work
> in practice, but it would certainly be very welcome. Having a try/catch
> block to intercept a segfault in native code would be fantastic.
>
>
> Best regards,
>
> Michael


More information about the panama-dev mailing list