<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<br>
<blockquote type="cite" cite="mid:CY4PR1001MB215074F751FC1A616A4701448C07A@CY4PR1001MB2150.namprd10.prod.outlook.com">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style>@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:10.0pt;
font-family:"Calibri",sans-serif;}p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
font-size:10.0pt;
font-family:"Calibri",sans-serif;}span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
mso-ligatures:none;}div.WordSection1
{page:WordSection1;}ol
{margin-bottom:0cm;}ul
{margin-bottom:0cm;}</style>
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US" lang="EN-US">I like the idea. It makes sense to simplify
handling of custom attributes for some common situations.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US" lang="EN-US">As the proposal adds a method to AtributeMapper
identifying “brittle” attributes, it still implies existence
of custom attribute mapper for each custom attribute.</span></p>
</div>
</blockquote>
<br>
Right now, there are two choices for modeling attributes:<br>
<br>
- 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. <br>
<br>
- 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. <br>
<br>
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.)<br>
<br>
Thinking some more about how to model this, a single bit is not good
enough. So I propose:<br>
<br>
enum AttributeStability { STATELESS, CP_REFS, LABELS, HAZMAT }<br>
<br>
(the names here are bad.)<br>
<br>
Where:<br>
<br>
- STATELESS means the attribute contains only pure data, such as
timestamps, and can always be bulk-copied. <br>
- 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<br>
- LABELS means that the attribute may contain labels, so should
always be exploded/rewritten<br>
- 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<br>
<br>
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. <br>
<br>
So the new API surface is:<br>
<br>
- an enum for the attribute's environmental coupling<br>
- an accessor on AttributeMapper for that enum<br>
- an option for what to do with HAZMAT attributes (which should
probably be merged with the option for UKNOWN attributes)<br>
<br>
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.<br>
<br>
<br>
<br>
<br>
<br>
<blockquote type="cite" cite="mid:CY4PR1001MB215074F751FC1A616A4701448C07A@CY4PR1001MB2150.namprd10.prod.outlook.com">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US" lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US" lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US" lang="EN-US">Current attributes can be split into following
categories :<o:p></o:p></span></p>
<ol style="margin-top:0cm" type="1" start="1">
<li class="MsoListParagraph" style="margin-left:0cm;mso-list:l2 level1 lfo1"><span style="font-size:11.0pt;mso-fareast-language:EN-US" lang="EN-US">Self-contained attributes (no dependency on
CP nor Code offsets). Such attributes can be safely
transformed in any situation and their payload is just
copy/pasted.<o:p></o:p></span></li>
<li class="MsoListParagraph" style="margin-left:0cm;mso-list:l2 level1 lfo1"><span style="font-size:11.0pt;mso-fareast-language:EN-US" lang="EN-US">Attributes with references to constant pool.
Such attributes can be safely transformed when the CP is
shared, however require custom handling (cloning of CP
entries) during write into a class with new CP.<o:p></o:p></span></li>
<li class="MsoListParagraph" style="margin-left:0cm;mso-list:l2 level1 lfo1"><span style="font-size:11.0pt;mso-fareast-language:EN-US" lang="EN-US">Attributes with references to bytecode
offsets (Code attributes). Payload of such attributes can
be safely copy/pasted only when the Code is untouched.
Otherwise they require custom translation into labeled
model during read and back to offsets during write. These
attribute most probably also use constant pool.</span><span style="font-size:11.0pt;mso-fareast-language:EN-US"><o:p></o:p></span></li>
</ol>
<p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US" lang="EN-US">I would suggest an alternative proposal to
provide various custom attribute mapper factories, mainly to
simplify handling of category #1 and #2 of custom
attributes.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US" lang="EN-US">That solution would not require to add any
indication methods to the mappers nor global switches. Each
custom mapper (composed by user) will respond to the actual
situation accordingly.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US" lang="EN-US">For category #1 there might be a single factory
getting attribute name and returning attribute mapper.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US" lang="EN-US">For category #2 there might be more options:<o:p></o:p></span></p>
<ul style="margin-top:0cm" type="disc">
<li class="MsoListParagraph" style="margin-left:0cm;mso-list:l0 level1 lfo3"><span style="font-size:11.0pt;mso-fareast-language:EN-US" lang="EN-US">A factory producing mapper which throws on
write when CP is not shared<o:p></o:p></span></li>
<li class="MsoListParagraph" style="margin-left:0cm;mso-list:l0 level1 lfo3"><span style="font-size:11.0pt;mso-fareast-language:EN-US" lang="EN-US">Or a factory producing mapper simplifying CP
entries clone and re-mapping on write when CP is not
shared (it might be implemented even the way the user
function identify offsets of CP indexes inside the payload
and mapper does all the job with CP entries re-mapping).
<o:p></o:p></span></li>
</ul>
<p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US" lang="EN-US">For category #3 we may also provide some mapper
factories, as we will better know specific use cases.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US" lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US" lang="EN-US">Thanks,
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US" lang="EN-US">Adam<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US" lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US" lang="EN-US"><o:p> </o:p></span></p>
<div id="mail-editor-reference-message-container">
<div>
<div style="border:none;border-top:solid #B5C4DF
1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span style="font-size:12.0pt;color:black">From:
</span></b><span style="font-size:12.0pt;color:black">classfile-api-dev
<a class="moz-txt-link-rfc2396E" href="mailto:classfile-api-dev-retn@openjdk.org"><classfile-api-dev-retn@openjdk.org></a> on behalf
of Brian Goetz <a class="moz-txt-link-rfc2396E" href="mailto:brian.goetz@oracle.com"><brian.goetz@oracle.com></a><br>
<b>Date: </b>Thursday, 27 July 2023 23:02<br>
<b>To: </b><a class="moz-txt-link-abbreviated" href="mailto:classfile-api-dev@openjdk.org">classfile-api-dev@openjdk.org</a>
<a class="moz-txt-link-rfc2396E" href="mailto:classfile-api-dev@openjdk.org"><classfile-api-dev@openjdk.org></a><br>
<b>Subject: </b>Attribute safety<o:p></o:p></span></p>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:13.5pt;font-family:"Courier
New"">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.
<br>
<br>
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.
<br>
<br>
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:<br>
<br>
- 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.)<br>
- 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.
<br>
- Drop the attribute during transformation and hope
that's OK. <br>
<br>
(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.)
<br>
<br>
I haven't been happy with any of the options, but I have
a proposal for incrementally improving it:<br>
<br>
- 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. <br>
<br>
- Add an option to determine what to do with brittle
attributes under transformation: drop them, retain them,
fail.
<br>
<br>
This way, nonstandard brittle attributes can be marked
as such as well, and get the same treatment as the known
brittle attributes.
<br>
<br>
</span><span style="font-size:11.0pt"><o:p></o:p></span></p>
</div>
</div>
</div>
</blockquote>
<br>
</body>
</html>