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

[Peter Levart]

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 
>>> and visible function be resolved.
>>
>> This however was unintentional, and I think you're right that this 
>> would ensure visibility:
>>
>>         function.resolve();
>>         UNSAFE.storeFence();
>>         FUNCTIONS[idx] = function;
>>
>> http://cr.openjdk.java.net/~redestad/8142334/webrev.04/
>>
>
> turns out the original order might've been necessary at least in 
> DirectMethodHandle.java to break a circular dependency:
>
>     at 
> java.lang.invoke.DirectMethodHandle.setCachedFunction(java.base at 9.0/DirectMethodHandle.java:659)
>     at 
> java.lang.invoke.DirectMethodHandle.getConstantFunction(java.base at 9.0/DirectMethodHandle.java:650)
>     at 
> java.lang.invoke.DirectMethodHandle.makePreparedLambdaForm(java.base at 9.0/DirectMethodHandle.java:232)
>     at 
> java.lang.invoke.DirectMethodHandle.preparedLambdaForm(java.base at 9.0/DirectMethodHandle.java:188)
>     at 
> java.lang.invoke.DirectMethodHandle.preparedLambdaForm(java.base at 9.0/DirectMethodHandle.java:177)
>     at 
> java.lang.invoke.DirectMethodHandle.make(java.base at 9.0/DirectMethodHandle.java:84)
>     at 
> java.lang.invoke.DirectMethodHandle.make(java.base at 9.0/DirectMethodHandle.java:104)
>     at 
> java.lang.invoke.DirectMethodHandle.make(java.base at 9.0/DirectMethodHandle.java:109)
>     at 
> java.lang.invoke.LambdaForm$NamedFunction.resolve(java.base at 9.0/LambdaForm.java:1078)
>     at 
> java.lang.invoke.DirectMethodHandle.setCachedFunction(java.base at 9.0/DirectMethodHandle.java:659)
>     at 
> java.lang.invoke.DirectMethodHandle.getConstantFunction(java.base at 9.0/DirectMethodHandle.java:650)
>     at 
> java.lang.invoke.DirectMethodHandle.makePreparedLambdaForm(java.base at 9.0/DirectMethodHandle.java:232)
>     at 
> java.lang.invoke.DirectMethodHandle.preparedLambdaForm(java.base at 9.0/DirectMethodHandle.java:188)
>     at 
> java.lang.invoke.DirectMethodHandle.preparedLambdaForm(java.base at 9.0/DirectMethodHandle.java:177)
>     at 
> java.lang.invoke.DirectMethodHandle.make(java.base at 9.0/DirectMethodHandle.java:84)
>     at 
> java.lang.invoke.DirectMethodHandle.make(java.base at 9.0/DirectMethodHandle.java:104)
>     at 
> java.lang.invoke.DirectMethodHandle.make(java.base at 9.0/DirectMethodHandle.java:109)
>     at 
> java.lang.invoke.LambdaForm$NamedFunction.resolve(java.base at 9.0/LambdaForm.java:1078)
>
> 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 
resolving works and tests pass, then perhaps it's all ok.

Peter

>
> ?
>
> /Claes