8263377: Store method handle linkers in the 'non-nmethods' heap

[yftsai]

---

Progress

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

Issue

• JDK-8263377: Store method handle linkers in the 'non-nmethods' heap

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 8760

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

Using diff file

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

[bridgekeeper[bot]]

:wave: Welcome back yftsai! 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[bot]]

@yftsai 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.

[openjdk[bot]]

@yftsai this pull request can not be integrated into master due to one or more merge conflicts. To resolve these merge conflicts and update this pull request you can run the following commands in the local repository for your personal fork:

git checkout intrinsics
git fetch https://git.openjdk.java.net/jdk master
git merge FETCH_HEAD
# resolve conflicts and follow the instructions given by git merge
git commit -m "Merge master"
git push

[mlbridge[bot]]

Webrevs

• 05: Full (f20fe0ff)
• 04: Full (f65f7c08)
• 03: Full (d92b8647)
• 02: Full - Incremental (e3e9f979)
• 01: Full - Incremental (00c99435)
• 00: Full (63771d64)

[dean-long]

I don't think we need a new RuntimeBlob subclasses. Can't we use the existing AdapterBlob or MethodHandlesAdapterBlob?

When changing from nmethod to CodeBlob, don't we need to replace COMPILED_METHOD_LOAD JVMTI events with DYNAMIC_CODE_GENERATED events?

[dean-long]

Looking at all the CompiledMethod --> CodeBlob changes, I wondering if it wouldn't be better to use a subclass of CompiledMethod, liked we did for AOT methods. However, there may be assumptions in the code that the only subclass of CompiledMethod is nmethod.

[dean-long]

/label hotspot-compiler

[openjdk[bot]]

@dean-long The hotspot-compiler label was successfully added.

[yftsai]

if it wouldn't be better to use a subclass of CompiledMethod

The idea has been explored in this earlier commit. Overall, it is more complex in reimplementing many CompiledMethod interfaces to support nmethod life cycle and GC scans. These interfaces are logically irrelevant to MH intrinsics which never unload and contain no oops.

[yftsai]

Can't we use the existing AdapterBlob or MethodHandlesAdapterBlob?

An MH intrinsic is handled differently from them in SharedRuntime::continuation_for_implicit_exception and compiledIC. The extra field _method is used in places like trace_exception unless this information is not important.

[bridgekeeper[bot]]

@yftsai This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

[bridgekeeper[bot]]

@yftsai This pull request has been inactive for more than 8 weeks and will now be automatically closed. If you would like to continue working on this pull request in the future, feel free to reopen it! This can be done using the /open pull request command.