Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8055911

Questionable String.intern() in jdk.nashorn.internal.ir.IdentNode()

    XMLWordPrintable

    Details

    • Type: Enhancement
    • Status: Resolved
    • Priority: P4
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 9
    • Component/s: core-libs
    • Subcomponent:
    • Resolved In Build:
      b29
    • CPU:
      generic
    • OS:
      generic

      Backports

        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, 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.

          Attachments

            Issue Links

              Activity

                People

                Assignee:
                attila Attila Szegedi
                Reporter:
                shade Aleksey Shipilev
                Votes:
                0 Vote for this issue
                Watchers:
                4 Start watching this issue

                  Dates

                  Created:
                  Updated:
                  Resolved: