-
Enhancement
-
Resolution: Fixed
-
P4
-
None
From: classfile-api-dev on behalf of Brian Goetz:
Right now, there are two choices for modeling attributes:
- No attribute mapper. Here, we will treat it as an unknown attribute, and use the option for unknown attribute handling to determine whether to preserve or drop the attribute.
- Attribute mapper present. Here, we currently assume that if there is an attribute mapper, we can pass the attribute through uninterpreted during transformation if the constant pool is shared, and we lift the attribute to the object form and re-render to bytes it if the constant pool is not shared.
We've tried to make it easy to write attribute mappers, to encourage people to do so. The implicit assumption in the attribute mapper design currently is that the only thing that might be environmentally sensitive is the constant pool. I think this is the assumption we want to refine. (Secondarily, the explode-and-rewrite trick can also tolerate labels moving, because labels are handled through a level of indirection.)
Thinking some more about how to model this, a single bit is not good enough. So I propose:
enum AttributeStability { STATELESS, CP_REFS, LABELS, HAZMAT }
(the names here are bad.)
Where:
- STATELESS means the attribute contains only pure data, such as timestamps, and can always be bulk-copied.
- CP_REFS means that the attribute contains only pure data and CP refs, so can be bulk-copied when CP sharing is in effect, and exploded/rewritten when CP sharing is not in effect
- LABELS means that the attribute may contain labels, so should always be exploded/rewritten
- HAZMAT means the attribute may contain indexes into structured not managed by the library (type variable lists, etc) and so we consult the "toxic attributes" option to determine whether to preserve or drop it
Most JVMS attributes are CP_REF. Some like Deprecated and CompilationID are STATELESS. The TA attributes are HAZMAT. The local variable table attributes are LABELS.
So the new API surface is:
- an enum for the attribute's environmental coupling
- an accessor on AttributeMapper for that enum
- an option for what to do with HAZMAT attributes (which should probably be merged with the option for UKNOWN attributes)
If stateless attributes were common, we might try to make life easier for attribute mapper writers by making the read/write methods optional for such attributes, but they are pretty uncommon so I think this is not worth it.
For more info see https://mail.openjdk.org/pipermail/classfile-api-dev/2023-July/000393.html
Right now, there are two choices for modeling attributes:
- No attribute mapper. Here, we will treat it as an unknown attribute, and use the option for unknown attribute handling to determine whether to preserve or drop the attribute.
- Attribute mapper present. Here, we currently assume that if there is an attribute mapper, we can pass the attribute through uninterpreted during transformation if the constant pool is shared, and we lift the attribute to the object form and re-render to bytes it if the constant pool is not shared.
We've tried to make it easy to write attribute mappers, to encourage people to do so. The implicit assumption in the attribute mapper design currently is that the only thing that might be environmentally sensitive is the constant pool. I think this is the assumption we want to refine. (Secondarily, the explode-and-rewrite trick can also tolerate labels moving, because labels are handled through a level of indirection.)
Thinking some more about how to model this, a single bit is not good enough. So I propose:
enum AttributeStability { STATELESS, CP_REFS, LABELS, HAZMAT }
(the names here are bad.)
Where:
- STATELESS means the attribute contains only pure data, such as timestamps, and can always be bulk-copied.
- CP_REFS means that the attribute contains only pure data and CP refs, so can be bulk-copied when CP sharing is in effect, and exploded/rewritten when CP sharing is not in effect
- LABELS means that the attribute may contain labels, so should always be exploded/rewritten
- HAZMAT means the attribute may contain indexes into structured not managed by the library (type variable lists, etc) and so we consult the "toxic attributes" option to determine whether to preserve or drop it
Most JVMS attributes are CP_REF. Some like Deprecated and CompilationID are STATELESS. The TA attributes are HAZMAT. The local variable table attributes are LABELS.
So the new API surface is:
- an enum for the attribute's environmental coupling
- an accessor on AttributeMapper for that enum
- an option for what to do with HAZMAT attributes (which should probably be merged with the option for UKNOWN attributes)
If stateless attributes were common, we might try to make life easier for attribute mapper writers by making the read/write methods optional for such attributes, but they are pretty uncommon so I think this is not worth it.
For more info see https://mail.openjdk.org/pipermail/classfile-api-dev/2023-July/000393.html
