FFM API summer update

[Maurizio Cimadamore]

On 27/07/2023 17:20, Gavin Ray wrote:
> Amazing, congrats to all involved!
>
> What are the odds that "RecordMapper" and "Improve ability to 
> visualize MemorySegments" will be available in the stable release?

I think our thinking around the mapper is in constant evolution, and 
we're now considering a bi-directional mapper that does both get AND set.

This allows applications to e.g. read bytes in a buffer as records, then 
to some work in the record domain, then commit all the records back to 
the buffer. We believe such an usage would unlock many 
serialization-like use cases.

Also, such a feature would work in harmony with some of the proposed 
enhancements to records, such as ability to create immutable copies:

https://github.com/openjdk/amber-docs/blob/master/eg-drafts/reconstruction-records-and-classes.md

I believe this work is important enough that it would be better off 
separated from the main FFM API JEP, and proceed orthogonally.

Cheers
Maurizio


>
> https://github.com/openjdk/panama-foreign/pull/833 
> <https://urldefense.com/v3/__https://github.com/openjdk/panama-foreign/pull/833__;!!ACWV5N9M2RV99hQ!NVtXVaZhncXaAXyT8ZvSUvYj4JS-DdoRrvH53UvEwHHiwsmD1EOAsaplsPSoIYbU0PVju2k1m39S9IdnJ2utUlqIiQcx$>
> https://github.com/openjdk/panama-foreign/pull/695 
> <https://urldefense.com/v3/__https://github.com/openjdk/panama-foreign/pull/695__;!!ACWV5N9M2RV99hQ!NVtXVaZhncXaAXyT8ZvSUvYj4JS-DdoRrvH53UvEwHHiwsmD1EOAsaplsPSoIYbU0PVju2k1m39S9IdnJ2utUrZJMyxQ$>
>
> 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
>         <https://urldefense.com/v3/__https://github.com/openjdk/panama-foreign/pull/840__;!!ACWV5N9M2RV99hQ!NVtXVaZhncXaAXyT8ZvSUvYj4JS-DdoRrvH53UvEwHHiwsmD1EOAsaplsPSoIYbU0PVju2k1m39S9IdnJ2utUnrcyI8a$>
>         [11] - https://git.openjdk.org/panama-foreign/pull/839
>         [12] - https://github.com/openjdk/panama-foreign/pull/833
>         <https://urldefense.com/v3/__https://github.com/openjdk/panama-foreign/pull/833__;!!ACWV5N9M2RV99hQ!NVtXVaZhncXaAXyT8ZvSUvYj4JS-DdoRrvH53UvEwHHiwsmD1EOAsaplsPSoIYbU0PVju2k1m39S9IdnJ2utUlqIiQcx$>
>         [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/7a9cfc74/attachment-0001.htm>