> 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 incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 72 additional commits since the last revision: - 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 - Fix typo in suggested fix - Update src/hotspot/share/oops/inlineKlassPayload.hpp Co-authored-by: Stefan Karlsson <[email protected]> - ... and 62 more: https://git.openjdk.org/valhalla/compare/eb80ccf7...e1834ba5 ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/2068/files - new: https://git.openjdk.org/valhalla/pull/2068/files/f5fb80fd..e1834ba5 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=2068&range=13 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=2068&range=12-13 Stats: 1444 lines in 73 files changed: 948 ins; 299 del; 197 mod Patch: https://git.openjdk.org/valhalla/pull/2068.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/2068/head:pull/2068 PR: https://git.openjdk.org/valhalla/pull/2068
