On Wed, 11 Feb 2026 10:09:46 GMT, Axel Boldt-Christmas <[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. > > Axel Boldt-Christmas has updated the pull request incrementally with two > additional commits since the last revision: > > - Avoid having to align label entires > - Fix BytecodeInterpreter dispatch table The dispatch mechanism in the BytecodeInterpreter was also not functioning, did not account for the new internal bytecodes. So fixed this as well. So with this patch you can at least build ZERO release and debug. (no functional testing done). ------------- PR Comment: https://git.openjdk.org/valhalla/pull/2068#issuecomment-3883935914
