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

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

    XMLWordPrintable

Details

    • Enhancement
    • Status: Resolved
    • P4
    • Resolution: Fixed
    • None
    • 9
    • core-libs
    • b29
    • generic
    • 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

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

                Dates

                  Created:
                  Updated:
                  Resolved: