Unifying memory addresses and memory segments
Maurizio Cimadamore
maurizio.cimadamore at oracle.com
Thu Sep 29 17:07:24 UTC 2022
On 29/09/2022 17:36, Glavo wrote:
> Thank you very much for your clarification, although I think some of
> them still need a very long wait...
>
> Also, I'll ask another, unrelated little question by the way: How to
> specify calling convention (cdecl / stdcall) in Valhalla? I didn't
> find anything relevant, am I missing something?
I think you mean Panama, not Valhalla?
We have recently added support for "Linker options" to the API [1], e.g.
options that alter the behavior of a linkage request; we plan to use
this for various things, such as:
* pinning of heap segments
* saving errno/LastError
* maybe deal with signals coming from native code (some libraries use
them to communicate errors)
* mark a native call as a "trivial" and omit native state transitions
* ...
I think adding support for different calling convention dialects is
something that can also be added in this way.
Maurizio
[1] - https://git.openjdk.org/panama-foreign/pull/734
>
> On Thu, Sep 29, 2022 at 11:10 PM Maurizio Cimadamore
> <maurizio.cimadamore at oracle.com> wrote:
>
> Hi,
> There are few things to be clarified here. Not all segments are
> created equals. If you create a segment and attach it to a "real"
> session, then escape analysis will fail (as the segment needs to
> be added to the session's list).
>
> But the segments returned by the linker (which used to be
> MemoryAddress instances) are simpler segment instances, which are
> backed by the "global" session. These instances are routinely
> scalarized (I believe folks working on LWJGL did some experiments
> on this, and reported few issues, which have now been fixed).
>
> Of course, if you take a zero-length memory segment, associated
> with the global session, and want to give it a size and a session
> (using MemorySegment::ofAddress), that's more expensive (but that
> is the same as before).
>
> Lastly, I don't think there's anything preventing us from turning
> MemorySegment into value classes, on paper. The tricky thing of
> doing that move is to make sure that C2 can see "what kind of
> segment are you dealing with", so that the underlying Unsafe
> access (for memory operation) can be sharp. In other words, C2
> needs to know if the segment has an associated "heap base" (and,
> if yes, what's the type of the base object) or not. Otherwise you
> end up with the so called "mixed access", where C2 wasn't able to
> prove that access was off-heap and extra barriers are inserted.
>
> That is why, at the moment, we have different memory segment
> implementations, one per "kind". We have an abstract class, and
> many leaves. Valhalla supports abstract classes too, but abstract
> classes need to have no field (which is something we can easily
> fix when needed).
>
> But I think the biggest gains would come from having a truly
> monomorphic memory segment implementation, although that requires
> some C2 optimizations (such as speculating on the types of some
> fields) which we do not have yet (but which will likely get more
> attention once Valhalla lands, as monomorphi-zation will become a
> trick that many people will want to play).
>
> So, in short - the proposed patch doesn't really alter performance
> characteristics (zero-length segments backed by global session are
> cheap to create and scalarize, like MemoryAddress). And I think
> there's no issue in making MemorySegment a value class, although,
> to fully reap benefits of Valhalla we might need more help from C2.
>
> Maurizio
>
>
> On 29/09/2022 15:13, Glavo wrote:
>> Sorry for the late reply to the email. I am more concerned about
>> the following things:
>>
>> 1. I've asked about Panama's interaction with Valhalla in
>> previous emails. At the time you said that MemoryAddress might
>> become a value class in the future.
>> The value class as a field type may be able to be stored
>> inline in the future. However, this is not possible with
>> MemorySegment.
>> 2. MemorySegment as a function parameter may be more difficult to
>> stack allocated when the function cannot be inlined.
>>
>> I'd like to be able to make native calls through Valhalla with
>> zero allocation, but this change seems to be further away from my
>> expectations, so I'm skeptical.
>> If I am wrong, I hope you can point it out for me, thanks!
>>
>> On Thu, Sep 1, 2022 at 5:04 AM Maurizio Cimadamore
>> <maurizio.cimadamore at oracle.com> wrote:
>>
>> What Paul says is correct, the existing benchmark showed no
>> regression
>> before/after the change.
>>
>> If you know of benchmarks that show a different picture now
>> would be the
>> ideal time to share them :-)
>>
>> I also note that, in your original message you wrote about a
>> detrimental
>> effect on "memory management". What do you mean by that?
>> Perhaps you
>> mean more objects being created on the heap?
>>
>> In principle, you can view a MemoryAddress in the old API as a
>> MemorySegment backed by the global memory session, whose base
>> address is
>> a certain native address, and its size is zero. So, if
>> clients want to
>> use a segment just to communicate an address in the new API,
>> and they
>> create such address-like segments with
>> `MemorySegment.ofLong(long)`, all
>> should be fine and escape analysis should work roughly the
>> same as
>> before. But again, if you have evidence of the contrary,
>> please let us know.
>>
>> Thanks
>> Maurizio
>>
>> On 25/08/2022 21:59, Paul Sandoz wrote:
>> >
>> >> On Aug 25, 2022, at 12:51 AM, Glavo <zjx001202 at gmail.com>
>> wrote:
>> >>
>> >> It looks good in terms of simplifying API design, but this
>> seems to have some detrimental effects on performance
>> optimization as well as memory management.
>> >>
>> > Can you please data you have on any performance regressions
>> you are observing?
>> >
>> >
>> >> Do we have some benchmarks to show changes in performance
>> and memory overhead (number of temporary objects created)?
>> >>
>> > I believe the existing micro benchmarks show no regressions:
>> >
>> >
>> https://github.com/openjdk/jdk/tree/master/test/micro/org/openjdk/bench/java/lang/foreign
>> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/tree/master/test/micro/org/openjdk/bench/java/lang/foreign__;!!ACWV5N9M2RV99hQ!P9lRjFpp2u31-nTmHGkNuffRc8WTHIY7ky-3q570E60HzEm3JKxfI6EqGgQPSLDBEbqIm4qlgjF_sJ6vS5JXRh6N1Q$>
>> >
>> > Paul.
>> >
>> >
>> >> On Tue, Jul 19, 2022 at 10:05 PM Maurizio Cimadamore
>> <maurizio.cimadamore at oracle.com> wrote:
>> >> Hi,
>> >> The Java 19 Foreign Function and Memory API (FFM API) uses
>> zero-length
>> >> memory segments to encode pointers that are temporally
>> safe (this
>> >> replaces the NativeSymbol abstraction that was available
>> in Java 18).
>> >> It turns out that there's more to this approach than meets
>> the eye, as
>> >> memory segments can (with few tweaks) be used as a
>> replacement for
>> >> memory address everywhere in the FFM API, which leads to a
>> simpler and
>> >> more symmetric API.
>> >>
>> >> We have captured our findings in the following document:
>> >>
>> >>
>> http://cr.openjdk.java.net/~mcimadamore/panama/segment_address.html
>> >>
>> >> Cheers
>> >> Maurizio
>> >>
>> >>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20220929/a26939aa/attachment-0001.htm>
More information about the panama-dev
mailing list