[lworld] RFR: 8377451: [lworld] Add ValuePayload abstraction [v17]
Axel Boldt-Christmas
aboldtch at openjdk.org
Tue Feb 24 07:15:16 UTC 2026
On Tue, 24 Feb 2026 06:31:49 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:
>> Create a wrapper class which represents the payload of an InlineKlass object.
>>
>> The current convention is to use a `void*` representing where the payload starts, the `InlineKlass*` (as we do not always have a header when flattened) and a `LayoutKind` (describing the payloads layout).
>>
>> I suggest we introduce something like a `ValuePayload` which encapsulate these properties. As well as a hierarchy built upon these, with the proper interfaces implemented.
>> * ValuePayload (Any payload)
>> * ~RawValuePayload (Payload with holder erased)~ (Removed in favour of using a static function)
>> * BufferedValuePayload (Payload of normal heap object)
>> * FlatValuePayload (Payload of flattened value)
>> * FlatFieldPayload (Payload of flattened field)
>> * FlatArrayPayload (Payload of flattened array element)
>>
>> The goal is to both make interfaces clearer, and easier to understand. As well as consolidating the implementation in one place rather than spread across different subsystems.
>>
>> Each type (except RawValuePayload) also allows for the creation of a Handle, (thread local, or in an OopStorage) for keeping the payload as a thread or global root.
>>
>> The ValuePayload class is also the interface for interacting with the Access API for InlineKlass objects.
>>
>> * Testing
>> * Running tier 1-4 with preview enabled
>> * Running app tests with preview enabled
>> * Running normal tier 1-5
>>
>> #### _Extra Notes:_
>> * The `OopHandle` type is there so that we can migrate the JVMTI payload abstraction implementation to using this instead. (Future RFE)
>> * Some interfaces got cleaned up. Some are unused. Like the `null_payload` which was superseded by the `Access::value_store_null`. C1 still uses the `.null_reset` but if that dependency is removed we should be able to remove that weird object all together.
>> * Simply adding the Java to VM transition deep inside the payload code created a circular include dependency here. So rather than fixing that, I implemented the relevant bytecodes in the BytecodeInterpreter.
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
>
> ZGC Barrier assert to strict
Thanks for all the reviews. Created follow-up RFEs for the issues identified in this PR.
-------------
PR Comment: https://git.openjdk.org/valhalla/pull/2068#issuecomment-3949699893
More information about the valhalla-dev
mailing list