-
Enhancement
-
Resolution: Future Project
-
P4
-
10
-
None
-
generic
-
generic
This is in relation to JDK-8059234. If we instrument C1 NCE and run Nashorn/Octane benchmark suite, and then sort the methods by compile time, we can then observe this:
http://cr.openjdk.java.net/~shade/8059235/nashorn-c1-nce.log.gz
The last lines there are most interesting:
34662 1541.935 ms, 11911 blocks: Done with null check elimination for method jdk/nashorn/internal/scripts/Script$Recompilation$2839$768791A$mandreel::_ZN16btCollisionWorld18addCollisionObjectEP17btCollisionObjectss(Ljdk/nashorn/internal/runtime/ScriptFunction;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
That is, a sample method took 1.5 seconds to do the a single phase in C1; and that is because it is a mammoth method with almost 12K basic blocks. While we can address the issue partially within JDK-8059234, Nashorn really needs to split the work into smaller methods to play nicely with JITs.
http://cr.openjdk.java.net/~shade/8059235/nashorn-c1-nce.log.gz
The last lines there are most interesting:
34662 1541.935 ms, 11911 blocks: Done with null check elimination for method jdk/nashorn/internal/scripts/Script$Recompilation$2839$768791A$mandreel::_ZN16btCollisionWorld18addCollisionObjectEP17btCollisionObjectss(Ljdk/nashorn/internal/runtime/ScriptFunction;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
That is, a sample method took 1.5 seconds to do the a single phase in C1; and that is because it is a mammoth method with almost 12K basic blocks. While we can address the issue partially within JDK-8059234, Nashorn really needs to split the work into smaller methods to play nicely with JITs.
- blocks
-
JDK-8059760 VM/JDK fixes for Nashorn performance (warmup/footprint, indy)
-
- Open
-
- relates to
-
JDK-8059234 C1 NullCheckEliminator consumes a lot of time when dealing with large methods
-
- Open
-