JDK-8038447 : WB API should support multi version of nmethod
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 9,11
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2014-03-27
  • Updated: 2020-05-08
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
Related Reports
Relates :  
JDK-8038240 - new WB API to get nmethod
Relates :  
JDK-8038356 - JVM should manage multiple versions of compiled methods
Description
On 03/26/2014 01:01 AM, John Rose wrote:
> The boolean parameter is not expressive enough.  It will have to change as soon as we have more than two versions of a method.
> 
> (In fact, we already do:  There is potentially a different OSR method for each entry point BCI.  The formulation you have returns just one of them.)
> 
> I suggest you change "boolean isOsr" in the WB API to "long version" or even "Object version".  The version enumeration can be evolved over time.  Values 0 and 1 can be "normal at current compilation" and "first available OSR".
> 
> Also, put the version number into the NMethod structure, so it can be requeried.  For an OSR method, the entry BCI is important to know.
> 
> ...But I see that there is already a use of booleans like this in the WB API.  So I guess you should consistent with what you have.
> 
> I filed a bug to track this issue of method versioning; there is technical debt here:
>    https://bugs.openjdk.java.net/browse/JDK-8038356
> 
> ��� John