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

[Peter Levart]

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);
     }


     private static NamedFunction makeConstantFunction(int idx) {
         try {
             switch (idx) {
                 case NF_internalMemberName:
                     return setCachedFunction(idx, new 
NamedFunction(DirectMethodHandle.class
                             .getDeclaredMethod("internalMemberName", 
Object.class)));
             ...



You could move a repeatable call to setCachedFuncion from individual 
cases of makeConstantFunction to getConstantFunction:

     private static NamedFunction getConstantFunction(int idx) {
         NamedFunction function = FUNCTIONS[idx];
         if (function != null) {
             return function;
         }
         return setCachedFunction(idx, makeConstantFunction(idx));
     }

     private static NamedFunction makeConstantFunction(int idx) {
         try {
             switch (idx) {
                 case NF_internalMemberName:
                     return new 
NamedFunction(DirectMethodHandle.class.getDeclaredMethod("internalMemberName", 
Object.class));
             ...



Regards, Peter

On 11/09/2015 06:51 PM, Claes Redestad wrote:
> 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, which somewhat defeats the purpose.
>
> By moving to per-MethodHandle and per-NamedFunction lazy 
> initialization, similar to existing code in java.lang.invoke.Invokers, 
> we improve the laziness generally: for a jigsaw Hello World the number 
> of LambdaForms created drops from 74 to 46, reducing heap occupancy 
> for a minimal application and measurably improving startup time.
>
> Webrev: http://cr.openjdk.java.net/~redestad/8142334/webrev.01
> Bug: https://bugs.openjdk.java.net/browse/JDK-8142334
>
> /Claes
>