Details
-
Enhancement
-
Resolution: Won't Fix
-
P4
-
None
-
None
-
generic
-
generic
Description
Profiling a simple scenario:
$ ~/Install/jdk9u20/bin/java -jar dist/nashorn.jar -Dnashorn.typeInfo.disabled=false --class-cache-size=0 --persistent-code-cache=false -scripting --log=time test/script/basic/compile-octane.js -- --iterations 5
...yields a few simple low-hanging fruits, here is one of them. Out of 320 seconds of run, and 38 seconds spent in class installation time, ~13 seconds are spent here:
12.690 jdk.nashorn.internal.codegen.CompilationPhase$12.transform(jdk.nashorn.internal.codegen.Compiler, jdk.nashorn.internal.codegen.Compiler$CompilationPhases, jdk.nashorn.internal.ir.FunctionNode)
5.220 jdk.nashorn.internal.runtime.Context$ContextCodeInstaller.initialize(java.util.Collection, jdk.nashorn.internal.runtime.Source, java.lang.Object[])
...
5.170 jdk.nashorn.internal.runtime.Context$ContextCodeInstaller$1.accept(java.lang.Class)
5.170 java.security.AccessController.doPrivileged(java.security.PrivilegedExceptionAction)
5.120 jdk.nashorn.internal.runtime.Context$ContextCodeInstaller$1$1.run()
5.000 java.lang.Class.getDeclaredField(java.lang.String)
4.940 java.lang.Class.privateGetDeclaredFields(boolean)
4.920 java.lang.Class.getDeclaredFields0(boolean)
4.890 JVM_GetClassDeclaredFields
4.610 InstanceKlass::link_class(Thread*)
4.770 InstanceKlass::link_class_impl(instanceKlassHandle,bool,Thread*)
3.700 Verifier::verify(instanceKlassHandle,Verifier::Mode,bool,Thread*)
3.630 ClassVerifier::verify_method(methodHandle,Thread*)
Update: See updated stack trace, it seems like the first call to getDeclaredFields causes the class to initialize and link. We spend the largest slob of time verifying the incoming bytecode.
$ ~/Install/jdk9u20/bin/java -jar dist/nashorn.jar -Dnashorn.typeInfo.disabled=false --class-cache-size=0 --persistent-code-cache=false -scripting --log=time test/script/basic/compile-octane.js -- --iterations 5
...yields a few simple low-hanging fruits, here is one of them. Out of 320 seconds of run, and 38 seconds spent in class installation time, ~13 seconds are spent here:
12.690 jdk.nashorn.internal.codegen.CompilationPhase$12.transform(jdk.nashorn.internal.codegen.Compiler, jdk.nashorn.internal.codegen.Compiler$CompilationPhases, jdk.nashorn.internal.ir.FunctionNode)
5.220 jdk.nashorn.internal.runtime.Context$ContextCodeInstaller.initialize(java.util.Collection, jdk.nashorn.internal.runtime.Source, java.lang.Object[])
...
5.170 jdk.nashorn.internal.runtime.Context$ContextCodeInstaller$1.accept(java.lang.Class)
5.170 java.security.AccessController.doPrivileged(java.security.PrivilegedExceptionAction)
5.120 jdk.nashorn.internal.runtime.Context$ContextCodeInstaller$1$1.run()
5.000 java.lang.Class.getDeclaredField(java.lang.String)
4.940 java.lang.Class.privateGetDeclaredFields(boolean)
4.920 java.lang.Class.getDeclaredFields0(boolean)
4.890 JVM_GetClassDeclaredFields
4.610 InstanceKlass::link_class(Thread*)
4.770 InstanceKlass::link_class_impl(instanceKlassHandle,bool,Thread*)
3.700 Verifier::verify(instanceKlassHandle,Verifier::Mode,bool,Thread*)
3.630 ClassVerifier::verify_method(methodHandle,Thread*)
Update: See updated stack trace, it seems like the first call to getDeclaredFields causes the class to initialize and link. We spend the largest slob of time verifying the incoming bytecode.
Attachments
Issue Links
- relates to
-
JDK-8053904 JVM Warmup: Investigate class installation overhead
- Closed
-
JDK-8055954 Questionable use of parallelStream() in jdk.nashorn.internal.runtime.Context$ContextCodeInstaller.initialize()
- Resolved