<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<span style="font-size:13.5pt;font-family:"Courier New""></span><br>
<span style="font-size:13.5pt;font-family:"Courier New""></span>
<blockquote type="cite" cite="mid:CY4PR1001MB2150959A66BB7762A36704908C479@CY4PR1001MB2150.namprd10.prod.outlook.com">
<div class="WordSection1">
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:13.5pt;font-family:"Courier New"">
- Does CodeLocalsShifter::addLocal work in concert with the
local-allocation feature of BlockBuilder?
<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US">Good point :)<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US">It does not yet, however I’ll try to
reimplement it to do so. We may get rid of counting the
method arguments, local counting of “next”, use
BlockBuilders instead of the “fork”, etc...</span></p>
</div>
</blockquote>
<br>
The local-allocation feature of BlockBuilder and friends is very
"green" right now. So I would not be surprised if you found
potholes. It also needs more tests. As you point out in your other
mail, there is nothing to stop the user from just "making up" local
slot allocations, and then of course there would be conflicts
between the automatic allocation and the user choices. We try to
detect this with this check:<br>
<br>
if (terminalMaxLocals != topLocal(terminal))<br>
throw new IllegalStateException("Interference in local
variable slot management");<br>
<br>
in BlockBuilder::end. (One case we do not have a test for is where
a stateful transform allocates a local in its atStart() method with
builder::allocateLocal, and then the transform uses
BlockBuilder::allocateLocal inside that.) <br>
<br>
The package Javadoc probably needs a section for local variable
management too, to explain how allocateLocal works, and what not to
do when using it. With some examples. <br>
<br>
<blockquote type="cite" cite="mid:CY4PR1001MB2150959A66BB7762A36704908C479@CY4PR1001MB2150.namprd10.prod.outlook.com">
<div class="WordSection1">
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US"><o:p></o:p></span></p>
<span style="font-size:13.5pt;font-family:"Courier
New""></span><br>
<span style="font-size:13.5pt;font-family:"Courier
New""></span>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:13.5pt;font-family:"Courier New"">
The ASM "util" package contains: Trace/CheckClassAdapter and
friends, ClassPrinter, etc. This feels in roughly the same
category -- stuff you may want to use, but which are
"components" rather than framework.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US">I think “commons” was not the best choice for
ASM, as it represent common (the bottom) parts of complex
APIs in many external Java libraries.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US">And I agree “transform” is too specific and
“util” is probably too general. <o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US">My personal preference would be “components”.<o:p></o:p></span></p>
<br>
</div>
</blockquote>
<br>
I think that's a fair choice. Just to validate that, here's some
other things I can imagine going in that bucket:<br>
<br>
- ClassPrinter <br>
- Utilities for parsing descriptor strings. To start with we might
cleanup the most useful ones that are currently internal. (Its
possible that these could eventually be used by java.lang.constant
too; there are too many ad-hoc copies of descriptor string parsers
in java.base.) <br>
<br>
<br>
</body>
</html>