> 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.
> My use if "observable to users" was not meant to include things that are implementation details anyway, like stack traces, CPU usage,
Ok. There's a lot of different ways re-resolution can be observed though - the most obvious would be a static counter updated each time the BSM is invoked. The value would be updated by re-resolutions.
--Dan
----- Original message -----
From: Dan Smith <daniel.sm...@oracle.com>
To: Daniel Heidinga <daniel_heidi...@ca.ibm.com>
Cc: valhalla-spec-experts@openjdk.java.net
Subject: Re: Final CONSTANT_Dynamic spec
Date: Wed, Feb 7, 2018 6:55 PM
The dashes (-----) are to delineate the actual spec. The sentence you're asking about is just me explaining for this mailing list how this rule interacts with our current implementation strategy.On Feb 4, 2018, at 9:59 AM, Daniel Heidinga <daniel_heidi...@ca.ibm.com> wrote:Dan,Can you clarify this sentence:----Note that an implementation is free to try to re-resolve X multiple times and keep looping until the stack actually overflows—once you've reached the nested X the first time, all further computation is not observable by users.----In particular this statement "not observable by users" has some unpleasant implications. Does that mean that side-effects that occur during the re-resolution should be undone?That the StackOverflowError's backtrace should only include a single loop of the re-resolution?There are a lot of ways that users could observe further computation and if the JVM needs to detect and prevent them from seeing the effects, this actually mandates early detection. Was that the intention or am I being overly pedantic?So, nothing being mandated here.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.My use if "observable to users" was not meant to include things that are implementation details anyway, like stack traces, CPU usage, debugger interactions, etc.—Dan
