Re: RFR: 8142334: Improve lazy initialization of java.lang.invoke

Thank you, Vladimir! /Claes On 2015-11-17 11:25, Vladimir Ivanov wrote: Looks good! Best regards, Vladimir Ivanov PS: I'm impressed by your courage and persistence, Claes :-) Untwining bootstrapping knot is notoriously hard, especially when you are new to the code. On 11/16/15 7:17 PM,

Re: RFR: 8142334: Improve lazy initialization of java.lang.invoke

> On 17 Nov 2015, at 11:25, Vladimir Ivanov > wrote: > > Looks good! > > Best regards, > Vladimir Ivanov > > PS: I'm impressed by your courage and persistence, Claes :-) Untwining > bootstrapping knot is notoriously hard, especially when you are new to the >

Re: RFR: 8142334: Improve lazy initialization of java.lang.invoke

Looks good! Best regards, Vladimir Ivanov PS: I'm impressed by your courage and persistence, Claes :-) Untwining bootstrapping knot is notoriously hard, especially when you are new to the code. On 11/16/15 7:17 PM, Claes Redestad wrote: Thanks for the explanation, and patience, Vladimir!

Re: RFR: 8142334: Improve lazy initialization of java.lang.invoke

Thanks for the explanation, and patience, Vladimir! Reworked: http://cr.openjdk.java.net/~redestad/8142334/webrev.09/ /Claes On 2015-11-16 13:49, Vladimir Ivanov wrote: The trick here is @Stable annotation. If the @Stable field is written to non-default value in constructor, it should be

Re: RFR: 8142334: Improve lazy initialization of java.lang.invoke

The trick here is @Stable annotation. If the @Stable field is written to non-default value in constructor, it should be equivalent to final field initialization. If the field is written to later, the initialization should be either idempotent or properly synchronized. I'd like to note that

Re: RFR: 8142334: Improve lazy initialization of java.lang.invoke

On 11/16/2015 01:49 PM, Vladimir Ivanov wrote: The trick here is @Stable annotation. If the @Stable field is written to non-default value in constructor, it should be equivalent to final field initialization. That changes my view completely. Thanks for clarifying. Regards, Peter

Re: RFR: 8142334: Improve lazy initialization of java.lang.invoke

NamedFunction.resolvedHandle should be usually pre-resolved, but for bootstrapping purposes it is done lazily in some cases. I don't see any reason why NamedFunction.resolve() should be called on a freshly created instance. Use proper constructor instead. NamedFunction(MethodHandle

Re: RFR: 8142334: Improve lazy initialization of java.lang.invoke

Hi Vladimir, On 11/14/2015 12:59 AM, Vladimir Ivanov wrote: NamedFunction.resolvedHandle should be usually pre-resolved, but for bootstrapping purposes it is done lazily in some cases. I don't see any reason why NamedFunction.resolve() should be called on a freshly created instance. Use

Re: RFR: 8142334: Improve lazy initialization of java.lang.invoke

Hi, On 2015-11-12 19:10, Paul Sandoz wrote: Hi Peter, This stuff always gives me a headache :-) Yes. :-) IIUC it’s all idempotent stuff, and the final field in NamedFunction should take care of certain things. That's been my understanding, as well. Claes, was it intentional that you

Re: RFR: 8142334: Improve lazy initialization of java.lang.invoke

On 2015-11-12 19:53, Peter Levart wrote: Do you think this would work correctly w.r.t visibility: FUNCTIONS[idx] = function; function.resolve(); UNSAFE.storeFence(); This does not do anything useful. What happens if you simply omit function.resolve() call. If lazy

Re: RFR: 8142334: Improve lazy initialization of java.lang.invoke

> On 11 Nov 2015, at 15:32, Claes Redestad wrote: > > Paul, > > On 2015-11-10 11:55, Paul Sandoz wrote: >> DirectMethodHandle >> — >> 682 private static @Stable NamedFunction[] FUNCTIONS = new >> NamedFunction[NF_LIMIT]; >> >> Invokers >> — >> 442 private

Re: RFR: 8142334: Improve lazy initialization of java.lang.invoke

On 2015-11-12 14:47, Paul Sandoz wrote: On 11 Nov 2015, at 15:32, Claes Redestad wrote: Paul, On 2015-11-10 11:55, Paul Sandoz wrote: DirectMethodHandle — 682 private static @Stable NamedFunction[] FUNCTIONS = new NamedFunction[NF_LIMIT]; Invokers — 442

Re: RFR: 8142334: Improve lazy initialization of java.lang.invoke

Hi Peter, This stuff always gives me a headache :-) IIUC it’s all idempotent stuff, and the final field in NamedFunction should take care of certain things. Claes, was it intentional that you call function.resolve() after the array store? You might need to reverse that and place a

Re: RFR: 8142334: Improve lazy initialization of java.lang.invoke

Hi, On 2015-11-12 17:26, Peter Levart wrote: Hi Claes, I have one concern... 645 private static NamedFunction getConstantFunction(int idx) { 646 NamedFunction function = FUNCTIONS[idx]; 647 if (function != null) { 648 return function; 649 } 650

Re: RFR: 8142334: Improve lazy initialization of java.lang.invoke

Hi Claes, It might be ok as you say, but then I don't understand the need to pre-resolve() NamedFunctions in original code. Do you? Regards, Peter On Nov 12, 2015 6:44 PM, "Claes Redestad" wrote: > Hi, > > On 2015-11-12 17:26, Peter Levart wrote: > >> Hi Claes, >> >>

Re: RFR: 8142334: Improve lazy initialization of java.lang.invoke

Hi Claes, I have one concern... 645 private static NamedFunction getConstantFunction(int idx) { 646 NamedFunction function = FUNCTIONS[idx]; 647 if (function != null) { 648 return function; 649 } 650 return setCachedFunction(idx,

Re: RFR: 8142334: Improve lazy initialization of java.lang.invoke

On 11/12/2015 07:50 PM, Claes Redestad wrote: Paul, On 2015-11-12 19:34, Claes Redestad wrote: Claes, was it intentional that you call function.resolve() after the array store? You might need to reverse that and place a Unsafe.storeFence between them if it is required that the published

Re: RFR: 8142334: Improve lazy initialization of java.lang.invoke

Paul, On 2015-11-12 19:34, Claes Redestad wrote: Claes, was it intentional that you call function.resolve() after the array store? You might need to reverse that and place a Unsafe.storeFence between them if it is required that the published and visible function be resolved. This however

Re: RFR: 8142334: Improve lazy initialization of java.lang.invoke

Hi Claes, On 11/11/2015 03:32 PM, Claes Redestad wrote: Paul, On 2015-11-10 11:55, Paul Sandoz wrote: DirectMethodHandle — 682 private static @Stable NamedFunction[] FUNCTIONS = new NamedFunction[NF_LIMIT]; Invokers — 442 private static @Stable NamedFunction[] FUNCTIONS = new

Re: RFR: 8142334: Improve lazy initialization of java.lang.invoke

Paul, On 2015-11-10 11:55, Paul Sandoz wrote: DirectMethodHandle — 682 private static @Stable NamedFunction[] FUNCTIONS = new NamedFunction[NF_LIMIT]; Invokers — 442 private static @Stable NamedFunction[] FUNCTIONS = new NamedFunction[NF_LIMIT]; MethodHandleImpl — 1627

Re: RFR: 8142334: Improve lazy initialization of java.lang.invoke

Hi Peter, On 2015-11-11 17:13, Peter Levart wrote: Hi Claes, Would constructing NamedFunction(s) using MemberName(s) directly, bypassing reflection, make any sense (for example in DMH): private static NamedFunction makeConstantFunction(int idx) { try { switch (idx) {

Re: RFR: 8142334: Improve lazy initialization of java.lang.invoke

> On 9 Nov 2015, at 20:48, Claes Redestad wrote: > > Hi Peter, > > nice catch: > > http://cr.openjdk.java.net/~redestad/8142334/webrev.02 > DirectMethodHandle — 682 private static @Stable NamedFunction[] FUNCTIONS = new NamedFunction[NF_LIMIT]; Invokers —

Re: RFR: 8142334: Improve lazy initialization of java.lang.invoke

Hi Peter, nice catch: http://cr.openjdk.java.net/~redestad/8142334/webrev.02 /Claes On 2015-11-09 20:26, Peter Levart wrote: Hi Claes, I see you apply this pattern consistently: private static NamedFunction getConstantFunction(int idx) { NamedFunction function = FUNCTIONS[idx];

RFR: 8142334: Improve lazy initialization of java.lang.invoke

Hi, across java.lang.invoke there are a number of inner Lazy classes whose purpose is to defer initialization of various internally used NamedFunctions and MethodHandles until first usage. The issue is that once *any* function or handle in these classes are referenced they're all initialized,

Re: RFR: 8142334: Improve lazy initialization of java.lang.invoke

Hi Claes, I see you apply this pattern consistently: private static NamedFunction getConstantFunction(int idx) { NamedFunction function = FUNCTIONS[idx]; if (function != null) { return function; } return makeConstantFunction(idx); }