Unifying memory addresses and memory segments

[Glavo]

Sorry for the typo, what I meant to say was indeed Panama.

I see, thanks a lot for your answer.

On Fri, Sep 30, 2022 at 1:07 AM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

>
> 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/20220930/18b16de9/attachment.htm>