-
Enhancement
-
Resolution: Fixed
-
P3
-
8u60, 9
-
b64
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8082703 | emb-9 | Vladimir Ivanov | P3 | Resolved | Fixed | team |
JDK-8072979 | 8u60 | Vladimir Ivanov | P3 | Closed | Won't Fix |
If you go ahead and profile Nashorn doing the entire suite of benchmarks:
~/trunks/jdk9-dev/build/linux-x86_64-normal-server-release/images/j2sdk-image/bin/java -jar ~/trunks/jdk9-dev/build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/ext/nashorn.jar -Dnashorn.typeInfo.disabled=false --class-cache-size=0 --persistent-code-cache=false -scripting --log=time test/script/basic/run-octane.js
...then you will see this profile:
http://cr.openjdk.java.net/~shade/8057967/native-call-tree-1.txt
There lots of <Unknown> things, and that is expected: Java code hides there. But, notice how bad we are at tracking the dependencies: out of 3070 seconds of CPU time, we spend 442 seconds (~15%!) trying to identify the dependencies to flush. It seems we are walking through InstanceKlass::_dependencies nmethods linked list, and trying to ask each nmethod if it needs deoptimizing. This is a linear search in the best case, and a very quick instrumentation with:
http://cr.openjdk.java.net/~shade/8057967/ik-trace-1.patch
...shows an immense miss rate when walking through that list. Notice the list size is also *growing*:
http://cr.openjdk.java.net/~shade/8057967/instrumented.log
We need to figure out whether we can:
a) Get less nmethods in the InstanceKlass::_dependencies list;
b) Re-index InstanceKlass dependency information based on the DepChange type and/or CallSite instance
c) Provide better statistics for dependency tracking events (akin to the brain-dead patch used above)
~/trunks/jdk9-dev/build/linux-x86_64-normal-server-release/images/j2sdk-image/bin/java -jar ~/trunks/jdk9-dev/build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/ext/nashorn.jar -Dnashorn.typeInfo.disabled=false --class-cache-size=0 --persistent-code-cache=false -scripting --log=time test/script/basic/run-octane.js
...then you will see this profile:
http://cr.openjdk.java.net/~shade/8057967/native-call-tree-1.txt
There lots of <Unknown> things, and that is expected: Java code hides there. But, notice how bad we are at tracking the dependencies: out of 3070 seconds of CPU time, we spend 442 seconds (~15%!) trying to identify the dependencies to flush. It seems we are walking through InstanceKlass::_dependencies nmethods linked list, and trying to ask each nmethod if it needs deoptimizing. This is a linear search in the best case, and a very quick instrumentation with:
http://cr.openjdk.java.net/~shade/8057967/ik-trace-1.patch
...shows an immense miss rate when walking through that list. Notice the list size is also *growing*:
http://cr.openjdk.java.net/~shade/8057967/instrumented.log
We need to figure out whether we can:
a) Get less nmethods in the InstanceKlass::_dependencies list;
b) Re-index InstanceKlass dependency information based on the DepChange type and/or CallSite instance
c) Provide better statistics for dependency tracking events (akin to the brain-dead patch used above)
- backported by
-
JDK-8082703 CallSite dependency tracking scales devastatingly poorly
-
- Resolved
-
-
JDK-8072979 CallSite dependency tracking scales devastatingly poorly
-
- Closed
-
- blocks
-
JDK-8059760 VM/JDK fixes for Nashorn performance (warmup/footprint, indy)
-
- Open
-
- relates to
-
JDK-8079205 CallSite dependency tracking is broken after sun.misc.Cleaner became automatically cleared
-
- Closed
-