Re: JDK-8145371 ClassCastException thrown in LambdaFormEditor.getInCache

On Wed, Jan 10, 2018 at 3:58 PM, Paul Sandoz wrote: > > The code is skating close to the edge and is definitely making you > uncomfortable :-) so I proposed making the field non-final but annotated > with @Stable, the same optimisations should still apply. > Sorry, @Stable doesn't increase my co

Re: JDK-8145371 ClassCastException thrown in LambdaFormEditor.getInCache

> On 9 Jan 2018, at 23:28, Martin Buchholz wrote: > > > > On Tue, Jan 9, 2018 at 4:50 PM, Paul Sandoz > wrote: > > >> On 9 Jan 2018, at 15:11, Martin Buchholz > > wrote: >> >> >> >> On Tue, Jan 9, 2018 at 2:42 PM, Paul Sandoz >

Re: JDK-8145371 ClassCastException thrown in LambdaFormEditor.getInCache

On Tue, Jan 9, 2018 at 4:50 PM, Paul Sandoz wrote: > > > On 9 Jan 2018, at 15:11, Martin Buchholz wrote: > > > > On Tue, Jan 9, 2018 at 2:42 PM, Paul Sandoz > wrote: > >> >> >> > On 9 Jan 2018, at 14:20, Martin Buchholz wrote: >> > >> > The memory model is already too hard to reason about, but

Re: JDK-8145371 ClassCastException thrown in LambdaFormEditor.getInCache

> On 9 Jan 2018, at 15:11, Martin Buchholz wrote: > > > > On Tue, Jan 9, 2018 at 2:42 PM, Paul Sandoz > wrote: > > > > On 9 Jan 2018, at 14:20, Martin Buchholz > > wrote: > > > > The memory model is already too hard to reason abou

Re: JDK-8145371 ClassCastException thrown in LambdaFormEditor.getInCache

On Tue, Jan 9, 2018 at 2:42 PM, Paul Sandoz wrote: > > > > On 9 Jan 2018, at 14:20, Martin Buchholz wrote: > > > > The memory model is already too hard to reason about, but here the VM > can assume that the final fields will never be mutated - yet they are! > > Because of reflection and Field/Ac

Re: JDK-8145371 ClassCastException thrown in LambdaFormEditor.getInCache

> On 9 Jan 2018, at 14:20, Martin Buchholz wrote: > > The memory model is already too hard to reason about, but here the VM can > assume that the final fields will never be mutated - yet they are! Because of reflection and Field/AccessibleObject.setAccessible the VM is conservative and doe

Re: JDK-8145371 ClassCastException thrown in LambdaFormEditor.getInCache

On Tue, Jan 9, 2018 at 4:12 AM, Vladimir Ivanov < vladimir.x.iva...@oracle.com> wrote: > > In the hotspot sources I find >>// An instance field can be constant if it's a final static field >> or if >>// it's a final non-static field of a trusted class (classes in >>// java.

Re: JDK-8145371 ClassCastException thrown in LambdaFormEditor.getInCache

Martin, The fix (MH.customize() part) looks good. Thanks for taking care of it! If there's a concurrent customization taking place, repeated read of MH.form can observe customized LF and repeat customization thus leading to a customized LF pointing to another customized LF (by LF.transformCa

Re: JDK-8145371 ClassCastException thrown in LambdaFormEditor.getInCache

In the hotspot sources I find // An instance field can be constant if it's a final static field or if // it's a final non-static field of a trusted class (classes in // java.lang.invoke and sun.invoke packages and subpackages). BUT you can't trust MethodHandle.form! Yes, it's

Re: JDK-8145371 ClassCastException thrown in LambdaFormEditor.getInCache

Hi Martin [Back from holiday] Can you reproduce using the debugger? If so do you have a more up to date stack trace? That change looks ok. The form field is final, and in the j.l.invoke package such fields are also stable so once C2 gets at it it will likely treat it as a constant. In general

Re: JDK-8145371 ClassCastException thrown in LambdaFormEditor.getInCache

That looks good to me. Vladimir Ivanov should take a look. Christmas vacation is just ending in Russia, so he should be around soon. On Jan 8, 2018, at 6:41 PM, Martin Buchholz wrote: > > No takers? ... let's try again. Despite uniform failure to reproduce this > except under a debugger, let'

Re: JDK-8145371 ClassCastException thrown in LambdaFormEditor.getInCache

No takers? ... let's try again. Despite uniform failure to reproduce this except under a debugger, let's apply the simple obviously correct fix, namely: /** Craft a LambdaForm customized for this particular MethodHandle */ /*non-public*/ void customize() { +final LambdaForm

Re: JDK-8145371 ClassCastException thrown in LambdaFormEditor.getInCache

Let's try again without mail bounces ... On Wed, Jan 3, 2018 at 1:40 PM, Martin Buchholz wrote: > Here at Google we tried to fix JDK-8145371 because it looked like it was > causing rare problems in production. But after looking at the code, I'm > not sure... Anyways, > > http://cr.openjdk.java

JDK-8145371 ClassCastException thrown in LambdaFormEditor.getInCache

Here at Google we tried to fix JDK-8145371 because it looked like it was causing rare problems in production. But after looking at the code, I'm not sure... Anyways, http://cr.openjdk.java.net/~martin/webrevs/jdk/MethodHandle.form/ https://bugs.openjdk.java.net/browse/JDK-8145371 Copying to a lo