RFR: 8364269: Simplify code cache API by storing adapter entry offsets in blob [v2]

[Andrew Dinn]

On Tue, 29 Jul 2025 13:28:15 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> The AOT stub blob save and restore API handles Adapter blobs differently to other single-stub blobs by passing the associated entries in a separate auxiliary array. Storing the entry offsets in the blob, as happens with other generated blobs, simplifies the current save/restore API and implementation. It also makes it easier to define and implement an API extension supporting save and restore of multi-stub (StubGen) blobs.
>
> Andrew Dinn 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 two additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8364269
>  - simplify code cache API by storing adapter entry offsets in blob

@vnkozlov @ashu-mehra  @shipilev

Ok, problem fixed, I believe, but I'm still gob-smacked that this built, ran and passed tier1 plus cds/appcds tests on Linux/aarch64 given the failure to run the exploded image on Linux/x86 and MacOS/aarch64.

The problem was with the blob layout. Adding extra fields to AdapterBlob requires propagating the adjusted blob size (i.e. header_size) up the Blob constructor chain, through BufferBlob into RuntimeBlob. Which I have now done -- previously, all subclasses were sized using sizeof(BufferBlob) as none of them had extra fields.

without that fix the content_start address for the Adpater blob was being reported in the tail of the blob proper which meant that in the broken builds data fields were being treated as code and we end up in hyperspace when we first use an i2c adapter to jump to Object.init(). Yet not on Linux/aarch64? Go figure.

Should be ready to review now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26532#issuecomment-3136689701