Attribute safety

[Brian Goetz]

On 7/27/2023 8:04 PM, Maurizio Cimadamore wrote:
>
>>
>> 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. ?

I was incomplete in my characterization.  LVT / LNT and other Code 
attribute-attributes have offsets into the code array, but these are 
mapped to Label and so can tolerate adaptation as well.  It is really 
the TA attributes that have "random crazy dependencies", though one can 
imagine nonstandard attributes also having random crazy dependencies.

>> 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.

Right, what I'm aiming at is something more like "can tolerate binary 
teleportation across classfiles if the CP is stable."  This is a middle 
ground that describes the vast majority of 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.

Yeah, the reality is that PC references are such a tiny part of the 
brittleness of TA attributes, that incurring lots of runtime cost for 
that one seems entirely wasted.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20230728/2e41dcdb/attachment.htm>