-
Enhancement
-
Resolution: Fixed
-
P4
-
None
-
b29
-
generic
-
generic
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8085691 | emb-9 | Attila Szegedi | P4 | Resolved | Fixed | team |
JDK-8064198 | 8u45 | Attila Szegedi | P4 | Resolved | Fixed | b01 |
JDK-8056158 | 8u40 | Attila Szegedi | P4 | Resolved | Fixed | b04 |
JDK-8070435 | emb-8u47 | Attila Szegedi | P4 | Resolved | Fixed | team |
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, 8 seconds are spent here:
8.410 jdk.nashorn.internal.ir.IdentNode.<init>(long, int, java.lang.String)
8.410 java.lang.String.intern()
I don't see off-hand why interning is needed for IdentNode.name. We compare through String.equals all the time. We escape the name via getName(), but Javadocs do not tell us to expect the interned String. If this is deduplication strategy, then doing the throw-away HashMap-based deduplication will save cycles going to VM, and save SystemDictionary from contamination.
Following up on this might require benchmarking to choose the proper interning/de-duplication strategy.
$ ~/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, 8 seconds are spent here:
8.410 jdk.nashorn.internal.ir.IdentNode.<init>(long, int, java.lang.String)
8.410 java.lang.String.intern()
I don't see off-hand why interning is needed for IdentNode.name. We compare through String.equals all the time. We escape the name via getName(), but Javadocs do not tell us to expect the interned String. If this is deduplication strategy, then doing the throw-away HashMap-based deduplication will save cycles going to VM, and save SystemDictionary from contamination.
Following up on this might require benchmarking to choose the proper interning/de-duplication strategy.
- backported by
-
JDK-8056158 Questionable String.intern() in jdk.nashorn.internal.ir.IdentNode()
-
- Resolved
-
-
JDK-8064198 Questionable String.intern() in jdk.nashorn.internal.ir.IdentNode()
-
- Resolved
-
-
JDK-8070435 Questionable String.intern() in jdk.nashorn.internal.ir.IdentNode()
-
- Resolved
-
-
JDK-8085691 Questionable String.intern() in jdk.nashorn.internal.ir.IdentNode()
-
- Resolved
-