JEP 442: Foreign Function & Memory API => why is it again preview API?

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Wed May 17 09:02:11 UTC 2023


On 17/05/2023 08:28, Uwe Schindler wrote:
> # You changed the lifetime abstractions in Java 20 and again in 21. To 
> me this is 2 rounds. After 19 people were not happy, so you added 20. 
> In 20 there was some additional cleanup (in my impression it was a 
> step back to Java 18 state just with different class names: 
> MemorySession -> Arena).

Another minor point (we discussed this before). While, it's true that 
Java 20 splits MemorySession into two abstractions and Java 21 seems to 
merge things back onto one, in reality things are more subtle. Java 21 
_still_ allows deallocation (and allocation) to be treated as a true 
capability: only code that has an Arena can close it (or allocate). This 
is **very** different from Java 18/19, where you could always ask a 
segment its scope and then close it, and created an issue where 
libraries could not, in the default configuration of the FFM API, share 
segments freely with untrusted clients.

The second very important difference is that Java 21, like Java 20 
allows clients to define custom arenas, which has always been one of the 
goals of the FFM API. As much as the JDK can try and define all the most 
common allocators, there will be always cases that will be left out. 
Allowing developers to define their own allocation scheme (as well as 
their own close policy) is IMHO a very big thing, and one we've been 
actively looking for after Java 19.

Again, I understand the frustration for having to deal with preview 
classfile versions and all. And I also understand that Lucene doesn't 
care about most of the stuff listed above (as I mentioend yesterday, the 
main thing for Lucene is the ability to close shared segments). But I 
also think we shouldn't fall into the trap of oversimplifying things: as 
explained, the memory API and the linker API have to work well together, 
and be flexible enough to handle use cases beyond what Lucene cares 
about (maybe, maybe not - perhaps one day Lucene will have its own 
wrappers around "mmap" using the Linker API :-) ). And we should, I 
think, make sure we get that balance right.

Maurizio

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20230517/b406d780/attachment-0001.htm>


More information about the panama-dev mailing list