On Mon, 9 Feb 2026 11:14:58 GMT, Stefan Karlsson <[email protected]> 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)
>> * 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.
>
> src/hotspot/share/interpreter/interpreterRuntime.cpp line 266:
>
>> 264:
>> 265: FlatFieldPayload payload(instanceOop(obj), entry);
>> 266: payload.write(inlineOop(value), CHECK);
>
> `obj_h` and `val_h` seems unused now.
Follow-up: Use `is_oop_or_null` instead.
> src/hotspot/share/oops/inlineKlassPayload.hpp line 68:
>
>> 66: inline ValuePayload(oop holder, InlineKlass* klass, ptrdiff_t offset,
>> 67: LayoutKind layout_kind
>> 68: DEBUG_ONLY(COMMA bool is_raw = false));
>
> To make it easier to read:
> Suggestion:
>
> inline ValuePayload(oop holder,
> InlineKlass* klass,
> ptrdiff_t offset,
> LayoutKind layout_kind
> DEBUG_ONLY(COMMA bool is_raw = false));
Or:
Suggestion:
inline ValuePayload(oop holder, InlineKlass* klass, ptrdiff_t offset,
LayoutKind layout_kind DEBUG_ONLY(COMMA bool is_raw =
false));
-------------
PR Review Comment:
https://git.openjdk.org/valhalla/pull/2068#discussion_r2782060222
PR Review Comment:
https://git.openjdk.org/valhalla/pull/2068#discussion_r2782192220
