Minor issue with stack map generator and generics

[David Lloyd]

OK, that makes sense. I can use the option. I still think the generics
usage isn't correct, but if all usages of the ad-hoc attributes are
internal then it's not a problem for users and if implementers are happy
with it then it's fine.

On Tue, Aug 29, 2023 at 8:27 AM Adam Sotona <adam.sotona at oracle.com> wrote:

> 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
>


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