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

[Claes Redestad]

Thanks Vladimir,

so something like this, then:

http://cr.openjdk.java.net/~redestad/8142334/webrev.06

I tried a similar approach after Peter's suggestions earlier, but got 
into bootstrapping issues which I failed to resolve at the time. Not 
having the DMH functions along for the ride simplifies greatly, so this 
approach now seems to work and passes various jtreg tests. There might 
even be a small initialization overhead improvement by not going via 
reflection.

/Claes

On 2015-11-14 00:59, 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 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