Attribute safety

[Brian Goetz]

We currently divide attributes into two buckets: those for which an 
attribute mapper exists, and those for which one doesn't.  The latter 
are represented with `UnknownAttribute`.  There is also an Option to 
determine whether unknown attributes should be discarded when reading or 
writing a classfile.  The main reason to be cautious about unknown 
attributes is that we cannot guarantee their integrity during 
transformation if there are any other changes to the classfile, because 
we don't know what their raw contents represent.

The library leans heavily on constant pool sharing to optimize 
transformation.  The default behavior when transforming a classfile is 
to keep the original constant pool as the initial part of the new 
constant pool.  If constant pool sharing is enabled in this way, 
attributes that contain only pure data and/or constant pool offsets can 
be bulk-copied during transformation rather than parsing and 
regenerating them.

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

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

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