Interaction between Panama and Valhalla

[Maurizio Cimadamore]

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