8366905: Store AdapterBlob pointer in AdapterHandlerEntry

[ashu-mehra]

This PR removes the need to store entry point addresses in AdapterHandlerEntry by storing a direct pointer to AdapterBlob instead. Entry point addresses can be computed on the fly from the entry point offsets stored in AdapterBlob.

---

Progress

• Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• Change must not contain extraneous whitespace
• Commit message must refer to an issue

Issue

• JDK-8366905: Store AdapterBlob pointer in AdapterHandlerEntry (Enhancement - P4)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/27101/head:pull/27101
$ git checkout pull/27101

Update a local copy of the PR:
$ git checkout pull/27101
$ git pull https://git.openjdk.org/jdk.git pull/27101/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 27101

View PR using the GUI difftool:
$ git pr show -t 27101

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/27101.diff

Using Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back asmehra! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

[openjdk]

@ashu-mehra The following label will be automatically applied to this pull request:

• hotspot

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

[ashu-mehra]

@adinn @shipilev I am finding it a bit challenging to handle zero configuration with this change. Now that the AdapterHandlerEntry has only a pointer to AdapterBlob, it is not possible to use zero_null_code_stub address as the i2c and c2i entry points. If the AdapterBlob is null, then the getter methods for entry points in AdapterHandlerEntry return nullptr. See get_i2c_entry, get_c2i_entry in sharedRuntime.hpp. And we stopped creating AdapterBlob for the AdapterHandlerEntry.
So the question is: for zero does it matter if we return zero_null_code_stub or nullptr? I remember at one point @shipilev was returning nullptr as the c2i entry address in one of the PR (#26746)

[shipilev]

So the question is: for zero does it matter if we return zero_null_code_stub or nullptr? I remember at one point @shipilev was returning nullptr as the c2i entry address in one of the PR (#26746)

It is fine to return nullptr for entry addresses in Zero. Zero is arguably out of line for recording external addresses as "entry points", even for the sake of better debugging. @adinn wanted to clean this up eventually, not sure we ever did.

[mlbridge]

Webrevs

• 00: Full (cad0d0c3)

[ashu-mehra]

This is ready for review now.

[ashu-mehra]

@adinn @shipilev can you please review this PR.