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