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

[Claes Redestad]

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];
        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