Classfile API support for JSR and RET instructions

[Brian Goetz]

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/20230420/55b4f30b/attachment.htm>