On Fri, 26 Sep 2025 15:58:04 GMT, Jatin Bhateja <[email protected]> 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
