> On Feb 12, 2018, at 10:05 PM, Daniel Heidinga <daniel_heidi...@ca.ibm.com> > wrote: > > > 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. > > 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.
Nope, it shouldn't. Example: Constant pool: ... #10 CONSTANT_Dynamic(BSM1, foo:I) #11 CONSTANT_Dynamic(BSM2, bar:D) #12 CONSTANT_Dynamic(BSM3, baz:J) BootstrapMethods: BSM1=invokestatic Bootstraps.m1(#1, #2, #11, #3) BSM2=invokestatic Bootstraps.m2(#4, #12, #5) BSM3=invokestatic Bootstraps.m3(#6, #10) 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: #1 #2 #4 #6 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. 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. 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. —Dan
