<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<br>
<br>
<div class="moz-cite-prefix">On 7/27/2023 8:04 PM, Maurizio
Cimadamore wrote:<br>
</div>
<blockquote type="cite" cite="mid:3afccb21-d44b-4575-cf20-30736d329620@oracle.com">
<br>
<blockquote type="cite" cite="mid:44eea6b4-f00e-154c-d3fd-3675a63934c9@oracle.com"><font size="4"><font face="monospace"> <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. <br>
</font></font></blockquote>
<font size="4"><font face="monospace">Don't other attributes have
this issue too? E.g. LocalVariableTable etc. ?</font></font><br>
</blockquote>
<br>
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. <br>
<br>
<blockquote type="cite" cite="mid:3afccb21-d44b-4575-cf20-30736d329620@oracle.com">
<blockquote type="cite" cite="mid:44eea6b4-f00e-154c-d3fd-3675a63934c9@oracle.com"><font size="4"><font face="monospace"> 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>
</font></font></blockquote>
<font size="4"><font face="monospace">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.</font></font><br>
</blockquote>
<br>
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.<br>
<br>
<blockquote type="cite" cite="mid:3afccb21-d44b-4575-cf20-30736d329620@oracle.com"><font size="4"><font face="monospace">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.</font></font><br>
</blockquote>
<br>
<font size="4"><font face="monospace">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.</font></font><br>
</body>
</html>