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

Type: Enhancement
Component: hotspot
Sub-Component: compiler
Affected Version: 17

Priority: P4
Status: Open
Resolution: Unresolved

Submitted: 2021-03-10
Updated: 2022-06-01

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

Other
tbdUnresolved

Raised after the discussion in this PR thread:

https://github.com/openjdk/jdk/pull/2523#discussion_r587460031

"I don't see a compelling reason why method handle linkers have to be nmethods and live in 'profiled'/'non-profiled' code heaps. I think the reason why it works that way now is the linkers are treated as ordinary native wrappers (since linker methods are just signature-polymorphic native static methods declared on java.lang.invoke.MethodHandle class). But native wrappers are represented as nmethods for a reason: they can be unloaded along with the class.
It's not the case with MH linkers which aren't unloaded at all."

MH linkers aren't unloaded and therefore could be stored in the 'non-nmethods' heap. It would be nice to investigate such a solution and it's benefits / drawbacks.