Minor issue with stack map generator and generics

[Adam Sotona]

Unfortunately jdk.internal.classfile.impl.StackMapGenerator is not exposed in the Classfile API and it is not designed to be called by user.
The right way to drive stack maps generation is through Classfile.StackMapsOption.
Where the default StackMapsOption.STACK_MAPS_WHEN_REQUIRED option will handle majority of use cases with maximum performance:

  *   transformations of valid classes keeping the original stack maps when the code is unchanged
  *   generation of stack maps for new methods
  *   however it does not fix invalid class files at the input of the transformation
StackMapsOption.GENERATE_STACK_MAPS option will force SM generation, for the cases like:

  *   stack maps should be generated even when not mandatory by JVMS
  *   source classes of the transformation are missing stack maps and Classfile API is used to fix it

There are several specific aspects of the stack maps generation:

  1.  Non-presence of  StackMapAttribute is a valid state for many methods, so this bare information is not enough to trigger the generator.
  2.  StackMapGenerator is internally invoked at the last stage of the code generation, where the bytecode array is fully constructed.


What specific use case are you trying to solve?

Thanks,
Adam


From: classfile-api-dev <classfile-api-dev-retn at openjdk.org> on behalf of David Lloyd <david.lloyd at redhat.com>
Date: Monday, 28 August 2023 18:51
To: classfile-api-dev at openjdk.org <classfile-api-dev at openjdk.org>
Subject: Minor issue with stack map generator and generics
I've been doing more experimenting with this API and ran across a minor issue. The way the stack map generator API is presently structured, it seems difficult to "get-or-generate".

For example, I thought to find the stack map for a method, or otherwise generate it if it did not exist, so my code looked something like this (structured for readability):

    MethodModel mm = ....;
    Optional<StackMapAttribute> optAttr = mm.findAttribute(Attributes.STACK_MAP_TABLE);
    StackMapAttribute sma = optAttr.orElseGet(() -> new StackMapGenerator(...).stackMapTableAttribute());

But this fails because `StackMapGenerator.stackMapTableAttribute()` returns an `Attribute<? extends StackMapAttribute>` instead of just `StackMapAttribute`. This method returns an anonymous subclass of `AdHocAttribute`; could it instead be changed to an inner class which also implements `StackMapAttribute`? I think this might be more correct as well because the type argument of `Attribute` seems like it was intended to be a self-type, and if so, these direct anonymous subclasses (and there are a few of them) seem to violate that intention.

--
- DML • he/him
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20230829/e43f2734/attachment-0001.htm>