Interaction between Panama and Valhalla

[Glavo]

>
> This is not true - going from a long to a MemoryAddress is not a
> restricted operation. Going from a MemoryAddress to a MemorySegment is.


Ah, sorry, I don't know why I have such a false memory.

Thank you very much for your reply.
I see your outstanding contributions in my eyes, and I wish Panama a better
future.

Cheers



On Tue, Mar 15, 2022 at 9:34 PM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> Hi,
> yes, flattening of memory address fields is far more important than
> flattening of MemoryAddress[], I agree.
>
> That said, flattening of MemoryAddress _fields_ is a somewhat simpler
> problem to solve, even for value-based classes.
>
> Note that the latest Valhalla document has a lot to say on the topic:
>
>
> https://openjdk.java.net/projects/valhalla/design-notes/state-of-valhalla/03-vm-model#flattening-and-representation
>
> And it explicitly states that, while flattening "bare" primitive classes
> is more straightforward than value classes, opportuntities for
> flattening do not end there.
>
> The main issue there when flattening a value class is how to encode the
> `null` value (assuming the value class utilizes its bit space in full,
> like MemoryAddress does). But, if the field is part of another bigger
> class, chances are that the VM will be able to "steal" an unused bit
> from the enclosing layout.
>
> None of this is supported by the current prototype, but it is very much
> in the spirit of what we want to achieve.
>
> > More importantly, the conversion between long and MemoryAddress
> > requires native access, which may prevent many third-party libraries
> > from performing such optimizations and bring unnecessary overhead.
> This is not true - going from a long to a MemoryAddress is not a
> restricted operation. Going from a MemoryAddress to a MemorySegment is.
> >
> > Another concern I have is that the interpreter and C1 compiler are far
> > less optimized than C2.
> > If in the future Panama is used more internally in the standard
> > library instead of JNI, and the interpreter and C1 lack the ability to
> > eliminate allocations, I'm concerned that this will slow down the cold
> > start of programs.
>
> True, but this problem is not specific to Panama (or its interaction
> with Valhalla). Any piece of code using Valhalla value/primitive classes
> will suffer from similar issues as it will need to wait for C2
> optimizations to kick in to reap the benefits.
>
> Cheers
> Maurizio
>
>