<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;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@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:1107967244;
mso-list-template-ids:1937943444;}
@list l1
{mso-list-id:1739326149;
mso-list-type:hybrid;
mso-list-template-ids:283157060 -28007644 134807577 134807579 134807567 134807577 134807579 134807567 134807577 134807579;}
@list l1:level1
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Calibri",sans-serif;
mso-fareast-font-family:"Times New Roman";}
@list l1:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l2
{mso-list-id:2105808681;
mso-list-template-ids:1592434732;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
--></style>
</head>
<body lang="en-CZ" link="#0563C1" vlink="#954F72" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">I thought
</span>PROCESS_STACK_MAP <span lang="EN-US">switch is clear the maps will pass to the CodeBuilder.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">It seems to me similar to PROCESS_DEBUG, PROCESS_LINE_NUMBERS and PROCESS_UNKNOWN_ATTRIBUTES.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">In all the above cases the relevant attributes appear or disappear from processing.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">I still “slightly” think that if user drops something specific to CodeBuilder – it should override even the Generator.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">However I’m ready to put Generator priority over the content dropped to CodeBuilder.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">What about another option to keep the status quo, drop
</span>PROCESS_STACK_MAP<span lang="EN-US"> switch and do not stream StackMapAttribute at all?<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">As users can still access it from CodeModel::findAttribute(Attributes.STACK_MAP_TABLE) and manually pass it to CodeBuilder, which will then override even Generator.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal" style="mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:12.0pt;margin-left:36.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>
<b>Date: </b>Wednesday, 17 August 2022 18:58<br>
<b>To: </b>Adam Sotona <adam.sotona@oracle.com>, classfile-api-dev@openjdk.org <classfile-api-dev@openjdk.org><br>
<b>Subject: </b>Re: RFR: Classfile API stack maps processing<o:p></o:p></span></p>
</div>
<p class="MsoNormal" style="margin-left:36.0pt"><br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoListParagraph" style="margin-left:72.0pt;text-indent:-18.0pt;mso-list:l2 level1 lfo1">
<![if !supportLists]><span style="mso-list:Ignore">1.<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]><span lang="EN-US">Processing stack maps is extremely advanced feature and 99.9% of users don’t want to touch it, so why
</span>PROCESS_STACK_MAP<span lang="EN-US"> is off by default and GENERATE_STACK_MAPS is on by default</span><o:p></o:p></p>
</div>
</blockquote>
<p class="MsoNormal" style="margin-left:36.0pt"><br>
Agree with this.<br>
<br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoListParagraph" style="margin-left:72.0pt;text-indent:-18.0pt;mso-list:l0 level1 lfo2">
<![if !supportLists]><span style="mso-list:Ignore">1.<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]><span lang="EN-US">When the 0.1% user needs to process the stack maps, he needs full control over it. So when user enables
</span>PROCESS_STACK_MAP<span lang="EN-US">, full control of what drops to code builder is up-to user.</span><o:p></o:p></p>
</div>
</blockquote>
<p class="MsoNormal" style="mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:12.0pt;margin-left:36.0pt">
<br>
OK, I don't mind two options, but I'd like to be clear on what they mean. I don't think that merely turning on PROCESS_STACK_MAP will clue the user in to the fact that they have disengaged all the safety guards. Some users may just want to _read_ the stack
map. So I'm OK with having both PROCESS and GENERATE options, but we should be clear what they mean, and be conservative in their meanings. Here's what makes sense to me:
<br>
<br>
GENERATE: the stack map is *always* generated by the library. Any stack maps sent downstream are still ignored.<br>
PROCESS: send the stack map to the user. <br>
PROCESS & !GENERATE: send the stack map to the user, write any stack map the user supplied to the classfile.
<br>
<br>
So users who want full control select PROCESS and !GENERATE; users who want to see the stackmap select PROCESS only; users who don't care about stack maps (which is most of them) select neither.
<br>
<br>
I think what this exposes is we need a way to override some options on a per-method basis, which is a separate problem.
<br>
<br>
<o:p></o:p></p>
</div>
</body>
</html>