Interaction between Panama and Valhalla

[Remi Forax]

----- Original Message -----
> From: "fazil mohamed" <fazil.mes53 at gmail.com>
> To: "Glavo" <zjx001202 at gmail.com>
> Cc: "panama-dev at openjdk.java.net'" <panama-dev at openjdk.java.net>, "jdk-dev" <jdk-dev at openjdk.java.net>, "valhalla-dev"
> <valhalla-dev at openjdk.java.net>
> Sent: Wednesday, March 2, 2022 7:09:53 AM
> Subject: Re: Interaction between Panama and Valhalla

> Hi Developers
> 
> Can anyone put some lights on Glavo's concerns. Although these features are
> under incubation/preview, JVMs inspired from OpenJDK are extremely focused
> on these JEPs and projects. In the near future the expectation is to define
> a method or variable using the Vector API(JEP-417) wrapper and can hold any
> primitive value type from Project Valhalla. Using project Panama memory
> layout, the developer can specify the size(32/64) and memory address within
> the heap of the defined. This reduces the GC time to Mark and Evacuate the
> space. These are all Hypothetical Thinking correct me if I'm wrong.

Remembers that those API are in preview mode, there is no backward compatibility issues for an API in preview (because there is no backward compatibility guarantee at all).

At some point in the future, vectors or MemoryAddress will be either a value class or a primitive class or whatever depending on how Valhalla evolve.
The closest we currently have is to mark a class as a value based class so at least you have some warnings by the compiler when you try to synchronize on it, etc.
It does not mean anything more.

regards,
Rémi

> 
> On Wed, Mar 2, 2022 at 9:27 AM Glavo <zjx001202 at gmail.com> wrote:
> 
>> Can someone answer my question?  Many thanks.
>>
>> On Thu, Jan 27, 2022 at 12:50 AM Glavo <zjx001202 at gmail.com> wrote:
>>
>> > I noticed that some Panama features seem to benefit from Valhalla's
>> > features. A notable example is MemoryAddress, which has been marked as
>> > value based and should be able to migrate to value classes in the future.
>> >
>> > However, this is not enough to satisfy me. MemoryAddress can be more than
>> > just a value class (identity-free reference type), but also a perfect
>> > candidate for the primitive class (JEP 401).
>> > It would be perfect if it could become a primitive class: Eliminates the
>> > possibility that Java's `null` being its value, we just need
>> > `MemoryAddress.NULL`;
>> > Such a small primitive class should almost always be flattened, storing
>> it
>> > in a field or array is as simple as a long
>> > (According to the description of JEP draft 8280173, when value class is
>> > stored in arrays and fields, it may not be flattened, and additional
>> > objects still need to be created)...
>> >
>> > However, what worries me is that the current Valhalla prototype does not
>> > seem to provide a way to migrate a class to a primitive class while
>> > maintaining compatibility.
>> > I'm worried that if Panama can't make it a primitive class before ending
>> > the preview, it will become a permanent regret.
>> > I don't know whether the two JDK preview functions can interact with each
>> > other, so here I want to ask if it is possible for Panama to have closer
>> > contact with Valhalla when Valhalla starts previewing at the same time?
>> >
>>
> 
> 
> --
> Regards
> 
> Mohamed Fasil