On Feb 14, 2018, at 12:06 PM, Daniel Heidinga
wrote:
>
> The stackoverflow in this example occurs in the static argument resolution
> phase, not the BSM invocation.
>
In one particular JVM implementation with which I am familiar,
an OS stack overflow occurred in the static argument resolut
Thanks for the clarification on this during the call today.
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.
To resolve CP entry 10, we would need to
* resolve the static arguments to BSM1 (#1, #2, #11
> On Feb 12, 2018, at 10:05 PM, Daniel Heidinga
> 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 fo
> 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 t
> On Feb 4, 2018, at 9:59 AM, Daniel Heidinga
> 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
On Feb 4, 2018, at 5:59 PM, Daniel Heidinga wrote:
>
> all further computation is not observable by users.
Yeah, that’s pretty loose. I don’t think anyone wants to propose rollback for
this corner case. Can anyone provide a better rephrase of the point?
(Who puts the dan in pedantic??)
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 sta
> On Jan 18, 2018, at 5:14 PM, Dan Smith wrote:
>
> A proposed final spec for CONSTANT_Dynamic is here:
>
> http://cr.openjdk.java.net/~dlsmith/constant-dynamic.html
>
> There are two significant changes:
>
> 5.4.3: Expanded the rule about concurrent resolution to account for nested
> resolut
On 1/19/2018 12:36 PM, Karen Kinnear wrote:
Looks great Dan - much clearer!
+1 for me too, I've read it through. Thanks Dan!
Lois
thanks,
Karen
On Jan 18, 2018, at 7:14 PM, Dan Smith wrote:
A proposed final spec for CONSTANT_Dynamic is here:
http://cr.openjdk.java.net/~dlsmith/constan
Looks great Dan - much clearer!
thanks,
Karen
> On Jan 18, 2018, at 7:14 PM, Dan Smith wrote:
>
> A proposed final spec for CONSTANT_Dynamic is here:
>
> http://cr.openjdk.java.net/~dlsmith/constant-dynamic.html
>
> There are two significant changes:
>
> 5.4.3: Expanded the rule about concur
> On 18 Jan 2018, at 17:43, John Rose wrote:
>
> On Jan 18, 2018, at 4:14 PM, Dan Smith wrote:
>>
>> A proposed final spec for CONSTANT_Dynamic is here:
>>
>> http://cr.openjdk.java.net/~dlsmith/constant-dynamic.html
>
>
> I gave it one more read. It is excellent. Let's do it. — John
On Jan 18, 2018, at 4:14 PM, Dan Smith wrote:
>
> A proposed final spec for CONSTANT_Dynamic is here:
>
> http://cr.openjdk.java.net/~dlsmith/constant-dynamic.html
I gave it one more read. It is excellent. Let's do it. — John
12 matches
Mail list logo
