Mapping byte code offsets in custom code attributes

[Rafael Winterhalter]

Hei Chen,

I would argue that code attributes are the most common type of custom
attributes, as attributes on other elements often can be expressed by
annotations. Even compilers for other languages on the JVM use annotations
where they can as of today. While code (type) annotations are supported,
many code attributes try to mark a segment of byte code, whereas code
annotations target a specific instruction. This is what makes them so
common. As a matter of fact, I thought about this recently, that Java could
likely make the need for custom code attributes obsolete if one could
annotate blocks of code such as in: @MyAnnotation { ... }, but of course
this is not an option today, and custom attributes will not disappear even
if this option was supported by the class file format.

With this background, almost all custom attributes I ever encountered were
code attributes that mark segments of code. Without an option to resolve a
bci to a label and vice versa, I already see a range of byte code power
users which will struggle to take the Class File API into use. At the same
time: ASM's supports this, but the API is complicated, so there is also a
good opportunity to offer a better user experience, if done right.

This is why I was hoping that bci could be avoided in the public API to
begin with. I already see some needed deprecation if one would needs to
adjust this later.

Thanks, Rafael

Am Mo., 11. Nov. 2024 um 00:28 Uhr schrieb Chen Liang <
chen.l.liang at oracle.com>:

> Hi Rafael,
> You are correct.  I had previously created an issue
> https://bugs.openjdk.org/browse/JDK-8341274 to track this demand.  Since
> this scenario has no way to bypass, maybe we can raise this issue to P3 and
> work on this feature for JDK 24.  Also I wonder how frequently are custom
> attributes storing BCIs?
>
> For LineNumberInfo: I believe the Label-based version, LineNumber, is
> already streamed in class file reading, and can be sent to the builder also
> via CodeBuilder::lineNumber(int).  Your particular use case can probably be
> covered by the RFE too, once we can convert labels to BCIs in non-Code
> attributes.
>
> Regards,
> Chen Liang
> ------------------------------
> *From:* classfile-api-dev <classfile-api-dev-retn at openjdk.org> on behalf
> of Rafael Winterhalter <rafael.wth at gmail.com>
> *Sent:* Saturday, November 9, 2024 2:32 AM
> *To:* classfile-api-dev <classfile-api-dev at openjdk.org>
> *Subject:* Mapping byte code offsets in custom code attributes
>
> Hello,
>
> I mentioned before that I think there is still a missing bit when it comes
> to custom code attributes, and mapping them using an AttributeMapper. Many
> code attributes point to a location, or area, within a method. This
> typically implies specifying one or two byte code offsets within an
> attribute.
>
> To implement this, I would need a possibility to translate offsets to
> labels within an attribute mapper, and vice versa. For example, if I
> created byte code from a different source, where a method consists of
> multiple files, I would want to mark what part of the method comes from
> what file.
>
> I do not currently know of a way to do this in the Class File API. To
> resolve this, I would have hoped that the attribute reader method would be
> able to issue labels that are later issued when the code instructions are
> supplied. Similarly, I would have hoped that the attribute writer method
> would be capable of translating labels to byte code offsets.
>
> In the same way, I would have hoped that all attributes such as
> LineNumberInfo of the LineNumberTableAttribute would expose bytecode
> offsets as labels and not as integers, as the latter does not really give
> any useful information by itself. This way, I could also write a custom
> LineNumberTableAttribute after a method is already created by issuing
> relevant labels, but by only writing the attribute when the entire method
> was visited. Sometimes this is necessary when generating code, when the
> information about the actual line numbers is only retrieved at a later
> stage that requires knowledge of the entire method.
>
> As I understand it, the ClassFile API is supposed to be released in Java
> 24. Are there still plans to integrate such a change? After that it would
> require incompatible changes, therefore I had hoped this would make it into
> the final version.
>
> Thanks! Rafael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20241111/2dbb739a/attachment.htm>