FFM API summer update

[Gavin Ray]

Amazing, congrats to all involved!

What are the odds that "RecordMapper" and "Improve ability to visualize
MemorySegments" will be available in the stable release?

https://github.com/openjdk/panama-foreign/pull/833
https://github.com/openjdk/panama-foreign/pull/695

On Thu, Jul 27, 2023 at 10:25 AM Chris Vest <mr.chrisvest at gmail.com> wrote:

> 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/53ed9ba8/attachment.htm>