Attribute safety

[Maurizio Cimadamore]

>
> Most of the known attributes meet this criteria -- that they contain 
> only pure data and/or constant pool offsets.  However, there are a 
> cluster of attributes that are more problematic: the type annotation 
> attributes.
Don't other attributes have this issue too? E.g. LocalVariableTable etc. ?
> These may contain offsets into the bytecode table, exception table, 
> list of type variables, bounds of type variables, and many other 
> structures that may be perturbed during transformation.  This leaves 
> us with some bad choices:
>
>  - Try to track if anything the attribute indexes into has been 
> changed.  (The cost and benefit here are out of balance by multiple 
> orders of magnitude here.)
The problem with this approach is that you need a semantic description 
of what the attribute is, in order to be able to understand whether its 
contents moved or not. Pack200 allowed this - e.g. it had a little 
layout language to describe custom classfile attributes, so that the 
pack200 tool could compress even attributes it didn't know about from 
the start. Pretty cool, but also hard to use, and probably adds complexity.
>  - Copy the attribute and hope it is good enough.  Much of the fine 
> structure of RVTA and friends are not actually used at runtime, so 
> this may be OK.
>  - Drop the attribute during transformation and hope that's OK.
Maybe an option to select which one of the last two behaviors you want?
>
> (There are also middle grounds, such as trying to detect whether the 
> entity with the attribute (method, field, etc) has been modified.  
> This is lighter-weight that trying to track if the attribute has been 
> invalidated, but this is already a significant task.)
>
> I haven't been happy with any of the options, but I have a proposal 
> for incrementally improving it:
>
>  - Add a method to AttributeMapper for to indicate whether or not the 
> attribute contains only pure data and/or constant pool offsets.  
> (Almost all the attributes defined in JVMS meet this restriction; only 
> the type annotation attributes do not.)  For purposes of this mail, 
> call the ones that do not the "brittle" attributes.
>
>  - Add an option to determine what to do with brittle attributes under 
> transformation: drop them, retain them, fail.
>
> This way, nonstandard brittle attributes can be marked as such as 
> well, and get the same treatment as the known brittle attributes.

It is a little awkward that the user feels like PC references are being 
adjusted in some attributes (exception tables, local variable related 
attributes), but not for TAs. Other than that looks good.


Maurizio

>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20230728/a8400219/attachment-0001.htm>