<div dir="ltr"><div>Hei Adam,</div><div><br></div><div>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.</div><div><br></div><div>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?</div><div><br></div><div>Best regards, Rafael<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Mi., 13. Nov. 2024 um 10:56 Uhr schrieb Adam Sotona <<a href="mailto:adam.sotona@oracle.com">adam.sotona@oracle.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="msg1099085259471431740">
<div lang="EN-US" style="overflow-wrap: break-word;">
<div class="m_1099085259471431740WordSection1">
<p class="MsoNormal"><span style="font-size:11pt">Hi Rafael,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt">Please correct me if I understand it wrong. In your email I see following requests:<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p>
<ol style="margin-top:0in" start="1" type="1">
<li class="m_1099085259471431740MsoListParagraph" style="margin-left:0in"><span style="font-size:11pt">Enable an option to override standard attribute mapper with a custom.<u></u><u></u></span></li></ol>
<p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt">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.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p>
<ol style="margin-top:0in" start="2" type="1">
<li class="m_1099085259471431740MsoListParagraph" style="margin-left:0in"><span style="font-size:11pt">Allow out-of-order construction of LineNumberTable attribute from labels.<u></u><u></u></span></li></ol>
<p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt">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.
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt">Adam<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p>
<div id="m_1099085259471431740mail-editor-reference-message-container">
<div>
<div>
<div style="border-width:1pt medium medium;border-style:solid none none;border-color:rgb(181,196,223) currentcolor currentcolor;padding:3pt 0in 0in">
<p class="MsoNormal" style="margin-bottom:12pt"><b><span style="color:black">From:
</span></b><span style="color:black">classfile-api-dev <<a href="mailto:classfile-api-dev-retn@openjdk.org" target="_blank">classfile-api-dev-retn@openjdk.org</a>> on behalf of Rafael Winterhalter <<a href="mailto:rafael.wth@gmail.com" target="_blank">rafael.wth@gmail.com</a>><br>
<b>Date: </b>Wednesday, 13 November 2024 at 8:51<br>
<b>To: </b>Chen Liang <<a href="mailto:chen.l.liang@oracle.com" target="_blank">chen.l.liang@oracle.com</a>><br>
<b>Cc: </b>classfile-api-dev <<a href="mailto:classfile-api-dev@openjdk.org" target="_blank">classfile-api-dev@openjdk.org</a>><br>
<b>Subject: </b>Re: [External] : Re: Mapping byte code offsets in custom code attributes<u></u><u></u></span></p>
</div>
<div>
<div>
<p class="MsoNormal">Hei Adam,<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Best regards, Rafael<span style="font-size:11pt"> </span><u></u><u></u></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div></blockquote></div>