Classfile API support for JSR and RET instructions

[Adam Sotona]

FYI: I’ve created new RFE JDK-8306650<https://bugs.openjdk.org/browse/JDK-8306650> Improve control of stack maps generation in Classfile API
to separate it from the actual bug fix of JDK-8305990<https://bugs.openjdk.org/browse/JDK-8305990> Stripping debug info of ASM 9.5 fails

Thank you,
Adam

From: Brian Goetz <brian.goetz at oracle.com>
Date: Thursday, 20 April 2023 16:00
To: Adam Sotona <adam.sotona at oracle.com>, classfile-api-dev at openjdk.org <classfile-api-dev at openjdk.org>
Subject: Re: Classfile API support for JSR and RET instructions
If a boolean is not sufficient, we can combine with the option refactor strategy I outlined yesterday:

    enum StackMapGenerationOption { ALWAYS, NEVER, FAIL_ON_JSR_RET, OMIT_ON_JSR_RET }
    record GenerateStackMaps(StackMapGenerationOption option) implements Option { }

On 4/20/2023 3:41 AM, Adam Sotona wrote:
Our strategy with stackmaps is to generate based on an option, whose default is to generate.  You are right that we should refine this so that we never generate stack maps for classfiles < 50 because the stackmap attribute wasn't defined until then.  But that leaves us with a quandary about what to do for 51; in your proposed changes below, there is no way a user could get a stack map table even if they wanted one and didn't use JSR/RET.  Instead, I think we should:

 - Generate a stackmap if the option is set and classfile version >= 50
 - If JSR/RET is generated in classfile > 51, throw from CodeBuilder
 - If stackmap generation encounters JSR/RET in classfile 50, throw from StackMapGenerator
The last condition unfortunately does not allow to agnostically process classes of unknown versions (the use case of jlink StripJavaDebugAttributesPlugin). If a classfile version 50 with JSR/RET instructions appears, there is no way how to turn off the stackmap generation for transformation of already parsed classfile. We have only a global boolean option for stackmap generation and it must be set before we know the class version. We may alternatively swallow the exception for classfile version 50 or call generator based on detection of JSR/RET for classfile version 50.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20230421/f5534b79/attachment-0001.htm>