<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@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;}
@font-face
{font-family:"Courier New \,serif";
panose-1:2 7 3 9 2 2 5 2 4 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:10.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
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.EmailStyle20
{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;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:404955724;
mso-list-template-ids:-683359544;}
@list l1
{mso-list-id:525948682;
mso-list-template-ids:-1285012730;}
@list l2
{mso-list-id:1254245348;
mso-list-template-ids:-2079275146;}
@list l2:level1
{mso-level-tab-stop:36.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l2:level2
{mso-level-tab-stop:72.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l2:level3
{mso-level-tab-stop:108.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l2:level4
{mso-level-tab-stop:144.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l2:level5
{mso-level-tab-stop:180.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l2:level6
{mso-level-tab-stop:216.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l2:level7
{mso-level-tab-stop:252.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l2:level8
{mso-level-tab-stop:288.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l2:level9
{mso-level-tab-stop:324.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l3
{mso-list-id:1976374089;
mso-list-template-ids:159669802;}
@list l3:level1
{mso-level-tab-stop:36.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l3:level2
{mso-level-tab-stop:72.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l3:level3
{mso-level-tab-stop:108.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l3:level4
{mso-level-tab-stop:144.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l3:level5
{mso-level-tab-stop:180.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l3:level6
{mso-level-tab-stop:216.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l3:level7
{mso-level-tab-stop:252.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l3:level8
{mso-level-tab-stop:288.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l3:level9
{mso-level-tab-stop:324.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
--></style>
</head>
<body lang="en-CZ" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<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"><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">Brian Goetz <brian.goetz@oracle.com><br>
</span><span style="font-size:13.5pt;font-family:"Courier New""><br>
</span><span lang="EN-US" style="font-size:13.5pt;font-family:"Courier New"">> </span>
<span style="font-size:13.5pt;font-family:"Courier New"">I am wondering about what is the practical difference between HAZMAT and UNKNOWN</span><span lang="EN-US" style="font-size:13.5pt;font-family:"Courier New"">.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US" style="font-size:11.0pt">Maybe there is no difference, all unknown attributes are HAZMAT, so we may drop UNKNOWN.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:13.5pt;font-family:"Courier New""><br>
</span><span lang="EN-US" style="font-size:13.5pt;font-family:"Courier New"">> </span>
<span style="font-size:13.5pt;font-family:"Courier New"">A related question is where we want to do the dropping. We could drop attributes either on the read side (never even present it to the user) or the write side. Currently we drop on read, but I think
this may not be ideal.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US" style="font-size:11.0pt">I think we should drop on both sides according to the actual context. When user parses classfile with option set to drop, the attributes are not expected to pass in.
However when the context for parsing allows the attributes and context for transformation don’t – they should pass in, however not pass out. </span><span style="font-size:13.5pt;font-family:"Courier New""><br>
<br>
</span><span lang="EN-US" style="font-size:13.5pt;font-family:"Courier New"">></span><span style="font-size:13.5pt;font-family:"Courier New""> AttributeProcessingOption is not a guarantee that such attributes would be dropped, just permission to do so if the
going gets tough. <o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US" style="font-size:11.0pt">Yes, this is common problem also for DebugElementsOption , LineNumbersOption and also for DeadCodeOption. For example to filter out debug attributes from code requires
to expand the code with no-op transformation down to the instructions, otherwise the option has no effect.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:13.5pt;font-family:"Courier New""><br>
</span><span lang="EN-US" style="font-size:13.5pt;font-family:"Courier New"">> </span>
<span style="font-size:13.5pt;font-family:"Courier New"">So I think what we need to discuss a little further is:<br>
- Better names in the AttributeStability enum <o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US" style="font-size:11.0pt">I like the HAZMAT :)<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:13.5pt;font-family:"Courier New""><br>
- When we should drop attributes according to the AttributeProcessingOption</span><span lang="EN-US" style="font-size:11.0pt"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US" style="font-size:11.0pt">I think on both sides according to the actual Classfile context.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US" style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US" style="font-size:11.0pt"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">On 8/1/2023 5:07 AM, Adam Sotona wrote:<o:p></o:p></span></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;mso-fareast-language:EN-US">FYI: I’ve created
<a href="https://bugs.openjdk.org/browse/JDK-8313452">JDK-8313452</a> and draft <a href="https://github.com/openjdk/jdk/pull/15101">
PR 15101</a> “</span><span style="font-size:11.0pt;mso-fareast-language:EN-US">Improve Classfile API attributes handling safety</span><span lang="EN-US" style="font-size:11.0pt;mso-fareast-language:EN-US">”</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;mso-fareast-language:EN-US">(the PR is targeted after
<a href="https://bugs.openjdk.org/browse/JDK-8312491">JDK-8312491</a> / <a href="https://git.openjdk.org/jdk/pull/14968">
PR 14968</a> is integrated due to Javadoc update and conflicts).</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;mso-fareast-language:EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;mso-fareast-language:EN-US">The custom attribute mapper simplification has lower priority and can be discussed independently.</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;mso-fareast-language:EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;mso-fareast-language:EN-US">Thanks,</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;mso-fareast-language:EN-US">Adam</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;mso-fareast-language:EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US"> </span><o:p></o:p></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">Brian Goetz <a href="mailto:brian.goetz@oracle.com">
<brian.goetz@oracle.com></a><br>
<b>Date: </b>Monday, 31 July 2023 16:00<br>
<b>To: </b>Adam Sotona <a href="mailto:adam.sotona@oracle.com"><adam.sotona@oracle.com></a>,
<a href="mailto:classfile-api-dev@openjdk.org">classfile-api-dev@openjdk.org</a> <a href="mailto:classfile-api-dev@openjdk.org">
<classfile-api-dev@openjdk.org></a><br>
<b>Subject: </b>Re: Attribute safety</span><o:p></o:p></p>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt"><br>
<br>
<br>
</span><o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;mso-fareast-language:EN-US">I like the idea. It makes sense to simplify handling of custom attributes for some common situations.</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;mso-fareast-language: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><o:p></o:p></p>
</blockquote>
<p class="MsoNormal"><span style="font-size:11.0pt"><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>
<br>
<br>
</span><o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;mso-fareast-language:EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;mso-fareast-language:EN-US">Current attributes can be split into following categories :</span><o:p></o:p></p>
<ol style="margin-top:0cm" start="1" type="1">
<li class="MsoListParagraph" style="margin-left:0cm;mso-list:l3 level1 lfo3"><span lang="EN-US" style="font-size:11.0pt;mso-fareast-language: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.</span><o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0cm;mso-list:l3 level1 lfo3"><span lang="EN-US" style="font-size:11.0pt;mso-fareast-language: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.</span><o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0cm;mso-list:l3 level1 lfo3"><span lang="EN-US" style="font-size:11.0pt;mso-fareast-language: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><o:p></o:p></li></ol>
<p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;mso-fareast-language: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.</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;mso-fareast-language: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.</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;mso-fareast-language:EN-US">For category #1 there might be a single factory getting attribute name and returning attribute mapper.</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;mso-fareast-language:EN-US">For category #2 there might be more options:</span><o:p></o:p></p>
<ol style="margin-top:0cm" start="1" type="1">
<li class="MsoListParagraph" style="margin-left:0cm;mso-list:l2 level1 lfo6"><span lang="EN-US" style="font-size:11.0pt;mso-fareast-language:EN-US">A factory producing mapper which throws on write when CP is not shared</span><o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0cm;mso-list:l2 level1 lfo6"><span lang="EN-US" style="font-size:11.0pt;mso-fareast-language: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).
</span><o:p></o:p></li></ol>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;mso-fareast-language:EN-US">For category #3 we may also provide some mapper factories, as we will better know specific use cases.</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;mso-fareast-language:EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;mso-fareast-language:EN-US">Thanks,
</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;mso-fareast-language:EN-US">Adam</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;mso-fareast-language:EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;mso-fareast-language:EN-US"> </span><o:p></o:p></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 href="mailto:classfile-api-dev-retn@openjdk.org">
<classfile-api-dev-retn@openjdk.org></a> on behalf of Brian Goetz <a 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 href="mailto:classfile-api-dev@openjdk.org">classfile-api-dev@openjdk.org</a>
<a href="mailto:classfile-api-dev@openjdk.org"><classfile-api-dev@openjdk.org></a><br>
<b>Subject: </b>Attribute safety</span><o:p></o:p></p>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:13.5pt;font-family:"Courier New ,serif",serif">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>
<br>
<br>
</span><o:p></o:p></p>
</div>
</div>
</blockquote>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
</div>
</div>
</blockquote>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
</div>
</div>
</div>
</body>
</html>