[lworld] RFR: 8367792: [lworld] Remove the Unsafe remnants of old valhalla prototypes

[Chen Liang]

On Fri, 26 Sep 2025 15:58:04 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> The vector support prototype was last updated 5 months ago. makePrivateBuffer introduces significant complexity into core library code and JVM. Besides this complexity, the vector prototype also introduces "multifield", which is also uncertain.
>> 
>> I will reach out to Paul Sandoz and Jatin Bhateja to check on the status of this prototype - it hasn't been updated since the new lworld model, maybe our mainline hacks can continue to work after the vector classes are marked value.
>
> Hi @liach , 
> 
> Currently, Unsafe.put* APIs expect to operate on a mutable value, without Unsafe.makePrivateBuffer, there is no way to transition a value object to larval state.
> 
> <img width="800" height="400" alt="image" src="https://github.com/user-attachments/assets/af826cda-55e1-4b0c-a2ea-62592f7623d6" />
> 
> 
> Here is a typical update kernel for the nary operation fallback implementation. 
> 
> <img width="500" height="200" alt="image" src="https://github.com/user-attachments/assets/4a31baa7-52b8-4e0b-8c42-924407bb5665" />
> 
> 
> 
> **Here are some relevant FAQs on the need for multifield annotation.**
> 
> Q. Why do we need @multifield annotated field in VectorPayloads and not just retain the array-backed backing storage?
> A.  Even currently, Vector instances are immutable, with each modification or application of an operation, a new vector is generated. 
>       Each new vector has a distinct backing storage in the form of an array; thus, no two vector ever share their backing storage, which makes vectors an immutable quantity. 
>       
>      Vector<Float>  newVector  =  Vec1.lanewise(VectorOperators.ADD, Vec2);
>      
> Since arrays are always allocated over the heap, they carry an identity, which is the distinctive heap address for each new backing storage array.
> 
> This contradicts the philosophy of value type instances, which are identity-free; the compiler treats two values with the same contents as equivalent entities and is free to substitute one with another. 
> 
> By replacing existing array-backed storage with a @multifield annotated storage, we ensure that payload adheres to true value semantics, a @multifiled is seen as a bundle of fields, encapsulating payload is a value class, unlike an array, a multifield is never allocated an explicit heap storage. 
> 
> Here is an example code
> 
>  
> <img width="388" height="503" alt="image" src="https://github.com/user-attachments/assets/8f6b5a07-a8e0-4912-b909-9d892f40d92a" />
> 
> 
> Even though Payload is a value class, its two instances with the same backing storage are not equal, because arrays have identity.
> By treating vectors as value objects, we expect that two vectors with the same contents should be equal.
> 
> Q.  Is there any alternative to @multifield?
> A.  All we need to ensure is that the backing storage has no identity.  Thus, we could have multiple primitive type fields in the payload, one for each lane of the vector. 
> 
>  
> <img width="450" height="310" alt="image" src="https://github.com/user-attachments/assets/af977c64-6373-4533-aceb-...

Hi @jatin-bhateja, as I know, the larval bit is completely unused in current Valhalla - I believe what we should do with that assert is to simply remove it. I am thinking of some internal API that accepts a Consumer that handles the "early larval" API via unsafe before returning it.

I thought the merge of lworld into vector would be trivial, but it turned out troublesome - can you push the merge as soon as it is ready? I am more than happy to help you migrate off makePrivateBuffer and this to-be-removed larval bit.

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/1593#issuecomment-3340696212