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

[Rafael Winterhalter]

Hei Adam,

as for (1): no I would not hope that would be needed. I just wanted to
point out that one could not override the attribute mappers, if one needed
to work with labels and write the attribute after the fact. If the label to
BCI translation happens in an AttributeMapper, one could neither patch in
the BCIs from labels.

As for (2), I understand the argument for performance reasons and the
possible work around. In this case, I would still prefer that I could
translate labels to BCIs after a method, and then at least insert the
LineNumberTableAttribute using these label based BCIs. What I still do not
understand here is how this allows to abstract over ranges, such as with
CharacterRangeTable which contains a start and a stop BCI. The attribute is
not inlined twice as I understand it? How can I get from the ending BCI in
the attribute to the end of the area that is marked?

Best regards, Rafael

Am Mi., 13. Nov. 2024 um 10:56 Uhr schrieb Adam Sotona <
adam.sotona at oracle.com>:

> 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.
>
>
>
>    2. 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/d07209f1/attachment.htm>