FFM API summer update

[Chris Vest]

This is excellent news.
Congratulations to the team on the big milestone!

Chris

On Thu, Jul 27, 2023 at 6:58 AM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> Hi all,
> As you know, the FFM API has been a Preview API since Java 19 [1]. The
> API was then re-previewed in 20 [2] and 21 [3]. Some of enhancements
> delivered in this timeframe were:
>
> * Unification of memory segments and memory addresses [4]
> * Treat arenas as "capabilities", so that memory segments can be safely
> shared [5, 6]
> * Allow for custom arenas [5, 6]
> * Add ways to customize linkage requests [7]
> * Add fallback linker, to facilitate porting FFM API to all platforms [8]
>
> We now believe that the FFM API is largely stable, and that, modulo
> disasters :-), it should exit preview in the next Java SE release:
>
> https://openjdk.org/jeps/8310626
>
> We have already started accumulating some changes in the panama
> repository which aim at polishing some minor edges in the API:
>
> * Add better support for "wide" native strings [9]
> * Make var handles derived from layouts more composable [10]
> * Add a linker method that can be used to discover platform-dependent
> mapping between C types and layouts [11]
>
> These changes are fairly minor, and should not have a big impact (if any
> at all) on existing code using the FFM API.
>
> Of course, the fact that FFM API is headed for finalization doesn't mean
> that development on FFM API will stop. There are several enhancements
> (aside from "regular" performance fixes) that we have been discussing
> over the years which can be delivered as follow-up JEPs:
>
> * Support for unsigned/complex types (needs Valhalla)
> * Mapping between structs and records [12]
> * Integration between Linker and JNI [13]
> * Structured arenas (depends on finalization of StructuredTaskScope) [14]
> * Pinning of heap segments
>
> (Of course, we have made sure that all the above enhancement can be
> delivered in an additive fashion, e.g. without the need to make
> incompatible changes to the FFM API)
>
> Finally, we'd like to thank all the developers who, over the years, have
> taken the time to take the API for a spin, try to build something with
> it and report feedback. This has been a long journey, and we wouldn't be
> where we are now without your help.
>
> Cheers
> Maurizio
>
> [1] - https://openjdk.org/jeps/424
> [2] - https://openjdk.org/jeps/434
> [3] - https://openjdk.org/jeps/442
> [4] - https://cr.openjdk.org/~mcimadamore/panama/segment_address.html
> [5] - https://cr.openjdk.org/~mcimadamore/panama/session_arenas.html
> [6] - https://cr.openjdk.org/~mcimadamore/panama/scoped_arenas.html
> [7] - https://git.openjdk.org/panama-foreign/pull/734
> [8] - https://git.openjdk.org/panama-foreign/pull/770
> [9] - https://git.openjdk.org/panama-foreign/pull/836
> [10] - https://github.com/openjdk/panama-foreign/pull/840
> [11] - https://git.openjdk.org/panama-foreign/pull/839
> [12] - https://github.com/openjdk/panama-foreign/pull/833
> [13] - https://mail.openjdk.org/pipermail/panama-dev/2023-May/019079.html
> [14] - https://cr.openjdk.org/~mcimadamore/panama/session_arenas.html
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20230727/90375733/attachment.htm>