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

[Vladimir Ivanov]

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 resolvedHandle)
         NamedFunction(MemberName member, MethodHandle resolvedHandle)
         NamedFunction(MethodType basicInvokerType)

         // The next 3 constructors are used to break circular 
dependencies on MH.invokeStatic, etc.
         // Any LambdaForm containing such a member is not interpretable.
         // This is OK, since all such LFs are prepared with special 
primitive vmentry points.
         // And even without the resolvedHandle, the name can still be 
compiled and optimized.
         NamedFunction(Method method) {
             this(new MemberName(method));
         }
         NamedFunction(Field field) {
             this(new MemberName(field));
         }
         NamedFunction(MemberName member) {
             this.member = member;
             this.resolvedHandle = null;
         }

There are 2 non-final fields in NamedFunction:
   static class NamedFunction {
       final MemberName member;
       @Stable MethodHandle resolvedHandle;
       @Stable MethodHandle invoker;

Repeated initialization of NamedFunction.invoker is benign since 
NamedFunction.computeInvoker uses synchronized 
MethodTypeForm.setCachedMethodHandle to populate the cache.

Regarding resolvedHandle, NamedFunction are usually constructed 
pre-resolved, but for the limited number of lazily initialized 
instances, I think we should force resolution right after bootstrapping 
is over.

Or, if you want to save on resolvedHandle resolution, replace all direct 
field accesses with accessor calls and synchronize when setting the 
value.

Best regards,
Vladimir Ivanov

On 11/12/15 10:11 PM, Claes Redestad wrote:
>
> 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
>> resolving works and tests pass, then perhaps it's all ok.
>>
>> Peter
>
> Actually, I simply tried backing out the DirectMethodHandle changes
> entirely, and measured how much we'd lose by leaving that particular
> case alone: almost nothing, as it turns out (same number of LFs are
> generated etc). I think the safest option is to leave DirectMethodHandle
> alone:
>
> http://cr.openjdk.java.net/~redestad/8142334/webrev.05/
>
> /Claes