<div class="socmaildefaultfont" dir="ltr" style="font-family:Arial, Helvetica, sans-serif;font-size:9pt" ><div dir="ltr" >Thanks for the clarification on this during the call today.</div>
<div dir="ltr" > </div>
<div dir="ltr" >Summarizing for any observers:  The BSMs won't have run yet because the JVM would still be setting up the arguments prior to invoking the BSM.  </div>
<div dir="ltr" >To resolve CP entry 10, we would need to</div>
<div dir="ltr" >* resolve the static arguments to BSM1 <span style="font-family: "Helvetica Neue", Helvetica, Arial, "Lucida Grande", sans-serif; background-color: rgb(255, 255, 255);" >(#1, #2, #11, #3)</span></div>
<div dir="ltr" >* which for CP entry 11, would require resolving the static arguments to BSM2 <span style="font-family: "Helvetica Neue", Helvetica, Arial, "Lucida Grande", sans-serif; background-color: rgb(255, 255, 255);" >(#4, #12, #5)</span></div>
<div dir="ltr" ><span style="font-family: "Helvetica Neue", Helvetica, Arial, "Lucida Grande", sans-serif; background-color: rgb(255, 255, 255);" >* which for CP entry 12, would require resolving the static arguments to BSM2 (#6, #10)</span></div>
<div dir="ltr" ><span style="font-family: "Helvetica Neue", Helvetica, Arial, "Lucida Grande", sans-serif; background-color: rgb(255, 255, 255);" >Which is the loop back to CP entry 10.</span></div>
<div dir="ltr" > </div>
<div dir="ltr" ><font face="Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif" ><span style="background-color: rgb(255, 255, 255);" >The stackoverflow in this example occurs in the static argument resolution phase, not the BSM invocation.  </span></font></div>
<div dir="ltr" > </div>
<div dir="ltr" ><font face="Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif" ><span style="background-color: rgb(255, 255, 255);" >BSMs that in use condy their implementation can result in side effects as expected when running user code.</span></font></div>
<div dir="ltr" > </div>
<div dir="ltr" ><font face="Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif" ><span style="background-color: rgb(255, 255, 255);" >--Dan</span></font></div>
<div dir="ltr" > </div>
<blockquote data-history-content-modified="1" dir="ltr" style="border-left:solid #aaaaaa 2px; margin-left:5px; padding-left:5px; direction:ltr; margin-right:0px" >----- Original message -----<br>From: Dan Smith <daniel.smith@oracle.com><br>To: Daniel Heidinga <Daniel_Heidinga@ca.ibm.com><br>Cc: valhalla-spec-experts@openjdk.java.net<br>Subject: Re: Final CONSTANT_Dynamic spec<br>Date: Tue, Feb 13, 2018 6:55 PM<br> <br><!--Notes ACF
<meta http-equiv="Content-Type" content="text/html; charset=utf8" >-->
<div><blockquote type="cite" ><div>On Feb 12, 2018, at 10:05 PM, Daniel Heidinga <<a href="mailto:Daniel_Heidinga@ca.ibm.com" target="_blank" >Daniel_Heidinga@ca.ibm.com</a>> wrote:</div> 

<div><div dir="ltr" style="font-family:Arial, Helvetica, sans-serif;font-size:9pt" ><div dir="ltr" ><div style="outline: none; font-family: "Helvetica Neue", Helvetica, Arial, "Lucida Grande", sans-serif;" >> That said, what side-effects are you concerned about? My claim is that re-resolution in this scenario would not, for example, trigger any class loading or bootstrap invocations.</div>
<div style="outline: none; font-family: "Helvetica Neue", Helvetica, Arial, "Lucida Grande", sans-serif;" > </div>
<div style="outline: none; font-family: "Helvetica Neue", Helvetica, Arial, "Lucida Grande", sans-serif;" >The simplest implementation strategy for a resolution that is guaranteed to throw SOF is to re-execute it each time the constant needs to be re-resolved and let the SOF reoccur naturally.  This would result in new BSM invocations.</div></div></div></div></blockquote>
<div> </div></div>Nope, it shouldn't.

<div> </div>
<div>Example:</div>
<div> </div>
<div>Constant pool:</div>
<div>...</div>
<div>#10 CONSTANT_Dynamic(BSM1, foo:I)</div>
<div>#11 CONSTANT_Dynamic(BSM2, bar:D)</div>
<div>#12 CONSTANT_Dynamic(BSM3, baz:J)</div>
<div> </div>
<div>BootstrapMethods:</div>
<div>BSM1=invokestatic Bootstraps.m1(#1, #2, #11, #3)</div>
<div>BSM2=invokestatic Bootstraps.m2(#4, #12, #5)</div>
<div>BSM3=invokestatic Bootstraps.m3(#6, #10)</div>
<div> </div>
<div>The spec says that, at the point where resolution of #10 is required by the program (e.g., an ldc), the following are resolved in order:</div>
<div>#1</div>
<div>#2</div>
<div>#4</div>
<div>#6</div>
<div> </div>
<div>Then the recursion reaches #10, and a SOE occurs. Rather than throwing immediately, the implementation may choose to begin resolution of #10 again, which will trigger re-resolution of #1, #2, #4, and #6, but all of those have completed previously so they're just cache lookups.</div>
<div> </div>
<div>None of the bootstrap methods m1, m2, or m3 would be invoked before the SOE, because we're still working on building an argument list. If #1, #2, #4, or #6 have bootstrap methods of their own, those would be invoked the first time and never again.</div>
<div> </div>
<div>You might be thinking of a different case: a bootstrap method that triggers another call to itself within its own body. That's not addressed at all by this rule. The expected behavior falls out from the rules for bytecode evaluation: either there will be some control flow changes to break the cycle, or the stack will run out and you'll get a vanilla SOE.</div>
<div> </div>
<div>—Dan</div></blockquote>
<div dir="ltr" > </div></div><BR>