On Mon, 23 Feb 2026 14:08:00 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)~ (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 with a new target base due > to a merge or a rebase. The pull request now contains 74 commits: > > - Merge remote-tracking branch 'upstream_valhalla/lworld' into > lworld-payload-rebase > - Merge remote-tracking branch 'upstream_valhalla/lworld' into > lworld-payload-rebase > - Merge remote-tracking branch 'upstream_valhalla/lworld' into > lworld-payload-rebase > - Destructor is a CHECK_UNHANDLED_OOPS property > - @shipilev formatted table > - Revert "Fix BytecodeInterpreter dispatch table" > > This reverts commit 59c1fc2e7dedd079a61dced4401267dace7c642d. > - Revert "Avoid having to align label entires" > > This reverts commit 342cd358eec59e1798ef62d03bbbd3a0e0f79d9d. > - Missed header guard rename > - Rename inlineKlassPayload files to valuePayload > - Add missing inline keywords > - ... and 64 more: > https://git.openjdk.org/valhalla/compare/7b3ac63d...02fada7d Thank you for this very clean refactoring and encapsulation of the value payload copying code. Copying a value's content is so complex and so specific that isolating this feature in its own files makes perfect sense. ------------- Marked as reviewed by fparain (Committer). PR Review: https://git.openjdk.org/valhalla/pull/2068#pullrequestreview-3843211667
