<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <br>
    <blockquote type="cite" cite="mid:CY4PR1001MB21508872EAD627DA301D3BBC8C6A9@CY4PR1001MB2150.namprd10.prod.outlook.com">
      
      <meta name="Generator" content="Microsoft Word 15 (filtered
        medium)">
      <style>@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: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;}div.WordSection1
        {page:WordSection1;}ol
        {margin-bottom:0cm;}ul
        {margin-bottom:0cm;}</style>
      <div class="WordSection1">
        <p class="MsoNormal"><span style="mso-fareast-language:EN-US" lang="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.</span></p>
      </div>
    </blockquote>
    <br>
    It is structurally similar, but (a) slightly different and (b) the
    danger level is much higher.  <br>
    <br>
    For PROCESS_{DEBUG,LINE_NUMBERS}, we explode the appropriate
    attribute into finer-grained elements, and reconstruct them into an
    attribute at the end.  (This reminds me that we need to make sure
    that we're not doing *both* reconstructed and pass-through
    processing in these cases.)  So this is opting into a more active
    mode of control over these elements.  And secondarily, messing up
    the line number tables or LVT will not result in unloadable
    classfiles.  <br>
    <br>
    It seem just too easy for a user to do the following:<br>
    <br>
     - request PROCESS_STACK_MAP because there is something useful they
    want to see in it, and just passing it through to the builder
    because that's a reasonable default for an element you don't plan to
    manipulate;<br>
     - adapt the instruction stream (say, to add logging), but without
    rewriting the stack map.<br>
    <br>
    Now, we will write a classfile with a wrong stack map.  This seems
    too easy and too dangerous.  Hence, asking users to _turn off_
    generation as well as turning on "give me stack maps" seems a
    reasonable precaution.  <br>
    <br>
    <blockquote type="cite" cite="mid:CY4PR1001MB21508872EAD627DA301D3BBC8C6A9@CY4PR1001MB2150.namprd10.prod.outlook.com">
      <div class="WordSection1">
        <p class="MsoNormal"><span lang="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">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.</span></p>
      </div>
    </blockquote>
    <br>
    We faced a similar situation with BootstrapMethods attribute. 
    THere, we concluded there is no case we want to let the user
    generate a BMA; if they want to generate BMA _entries_, they can do
    so with ConstantPoolBuilder.  There are various places where we
    filter out BMA in various places, such as attributes written to the
    ClassBuilder.  Stack maps feel about 90% along on the spectrum of [
    line numbers ... bootstrap methods ] to me.  <br>
    <br>
    <blockquote type="cite" cite="mid:CY4PR1001MB21508872EAD627DA301D3BBC8C6A9@CY4PR1001MB2150.namprd10.prod.outlook.com">
      <div class="WordSection1">
        <p class="MsoNormal"><span lang="EN-US"><o:p></o:p></span></p>
        <p class="MsoNormal"><span lang="EN-US"><o:p> </o:p>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.</span></p>
      </div>
    </blockquote>
    <br>
    This is more in line with how we handle BootstrapMethod attribute,
    and I think it is fine.  I think it is better, actually, because
    there is  no confusion about the interaction between "process" and
    "generate".  Here, "generate" indicates clear control over what to
    do with user-provided stack maps -- if we are in generate mode,
    ignore the user one.  No confusion.  So, +1 to this idea.<br>
    <br>
    <blockquote type="cite" cite="mid:CY4PR1001MB21508872EAD627DA301D3BBC8C6A9@CY4PR1001MB2150.namprd10.prod.outlook.com">
      <div class="WordSection1">
        <p class="MsoNormal"><span lang="EN-US"><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
              <a class="moz-txt-link-rfc2396E" href="mailto:brian.goetz@oracle.com"><brian.goetz@oracle.com></a><br>
              <b>Date: </b>Wednesday, 17 August 2022 18:58<br>
              <b>To: </b>Adam Sotona <a class="moz-txt-link-rfc2396E" href="mailto:adam.sotona@oracle.com"><adam.sotona@oracle.com></a>,
              <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>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>
    </blockquote>
    <br>
  </body>
</html>