[External] : Re: Mapping byte code offsets in custom code attributes

[Adam Sotona]

Hi Rafael,
Please correct me if I understand it wrong. In your email I see following requests:


  1.  Enable an option to override standard attribute mapper with a custom.

Overriding of standard attribute mappers is not allowed in the Class-File API as it would result in nondeterministic behavior. Standard attributes parsing, transformation and generation is always handled by Class-File API.


  1.  Allow out-of-order construction of LineNumberTable attribute from labels.

LineNumber pseudo-instructions are inlined for performance reason. Inflation of a label for each line number will multiply number of label targets and degrade performance of Class-File API and significantly degrade performance of all flow-graph construction transformations. You can always create a two-pass transformation if you insist on out-of-order line numbers insertion. There is nothing preventing you to insert labels to the line number positions (or replace the line numbers with labels) in a first pass, transform your own aggregated map and apply the changes (if any) in a second pass. Code transformations can be chained so you do not lose much on performance.

Adam


From: classfile-api-dev <classfile-api-dev-retn at openjdk.org> on behalf of Rafael Winterhalter <rafael.wth at gmail.com>
Date: Wednesday, 13 November 2024 at 8:51
To: Chen Liang <chen.l.liang at oracle.com>
Cc: classfile-api-dev <classfile-api-dev at openjdk.org>
Subject: Re: [External] : Re: Mapping byte code offsets in custom code attributes
Hei Adam,
as for ASM, I also think that the inline visiting of code type annotations without a label is a limitation in its API design. It does not apply as much to the tree API where one can walk up the stack to insert an annotation in the correct position, but I have seen this being a hassle in the visitor API, requiring a second pass. Not so much for annotations, but for try-catch-segments, this is a particular problem and I have gone as far as writing the exception table attribute by hand, which ASM allows by implementing a custom Attribute. The class file format is flexible when it comes to setting attributes independently from the attributed code, and I therefore believe that this should be the primary abstraction. I have no problem with the concept of pseudo instructions, but personally, I would have dropped them and asked users to request if label positions represent something that is not related to other instructions. Most people who instrument code do either not care about attributes at all, or they do in what case they exactly know what they want to do, and what attribute to access for such metadata.
As you say, everything can be worked around, but this is my belief based on my experience with using ASM. This is why I had hoped that all attributes could still be label-centric and always allow for manual definition after creating the code attribute. This way, power-users get the freedom they want, while others might still want to visit the inline pseudo-instructions for their convenience.
Best regards, Rafael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20241113/7e234d23/attachment-0001.htm>