RFR: 8164525: Re-examine zero form link time pre-generation

Claes Redestad claes.redestad at oracle.com
Sun Aug 21 09:59:43 UTC 2016


Hi,

the previous attempt to pre-generate zero LambdaForms[1] failed
due to the current implementation surprisingly emitting placeholder
constants to link to the associated identity function (which we can't
properly handle when pre-generating forms) rather than simply emitting
the corresponding bytecode directly (iconst_0, etc).

It turns out the setup of Zero and Identity functions aren't being made
intrinsic, which appears to be an oversight. Fixing this allows for more 
optimal bytecode[1].

While this fix could have positive performance implications in general,
it also makes the startup optimization from JDK-8164451 re-apply
without issue (no test failures running RBT --test jdk/test/:tier1).

Bug: https://bugs.openjdk.java.net/browse/JDK-8164525
Webrev: http://cr.openjdk.java.net/~redestad/8164525/webrev.01/

Thanks!

/Claes

[1] https://bugs.openjdk.java.net/browse/JDK-8164451
[2] Before:

   static java.lang.Object zero_000_L(java.lang.Object);
     descriptor: (Ljava/lang/Object;)Ljava/lang/Object;
     flags: ACC_STATIC
     Code:
       stack=2, locals=1, args_size=1
          0: ldc           #14                 // String 
CONSTANT_PLACEHOLDER_1 <<(Object)Object : 
identity_000_L=Lambda(a0:L,a1:L)=>{a1:L}\n& Class=SimpleMethodHandle>>
          2: checkcast     #16                 // class 
java/lang/invoke/MethodHandle
          5: aconst_null
          6: invokevirtual #19                 // Method 
java/lang/invoke/MethodHandle.invokeBasic:(Ljava/lang/Object;)Ljava/lang/Object;
          9: areturn
     RuntimeVisibleAnnotations:
       0: #8()
       1: #9()
       2: #10()

After:

   static java.lang.Object zero_L(java.lang.Object);
     descriptor: (Ljava/lang/Object;)Ljava/lang/Object;
     flags: ACC_STATIC
     Code:
       stack=1, locals=1, args_size=1
          0: aconst_null
          1: areturn
     RuntimeVisibleAnnotations:
       0: #8()
       1: #9()
       2: #10()


More information about the core-libs-dev mailing list