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

Use Unsafe.defineAnonymousClass for loading Nashorn script code

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: P3
    • Resolution: Fixed
    • Affects Version/s: 9
    • Fix Version/s: 9
    • Component/s: core-libs
    • Labels:
      None
    • Subcomponent:
    • Resolved In Build:
      b83
    • CPU:
      generic
    • OS:
      generic

      Backports

        Description

        We should use Unsafe.defineAnonymousClass to load Nashorn script code. We can cut down significantly on the number of class loaders (as we no longer need one per compilation job in order for the generated classes to be GC eligible). Anonymous classes are said to be more aggressively optimized (at least that's what Aleksey Shipilev told me). Class installation time also gets reduced to 80% of what it was before.

          Issue Links

            Activity

            Hide
            attila Attila Szegedi added a comment -
            Some performance results:

            running Octane suite for 2 iterations (excluding typescript and zlib as they're really slow) takes 276s on my machine; after switching to VM anon classes it takes 265s. Of that, 10s and 8s are spent installing classes, respectively. "ant test" (preceded by separate "ant jar" so everything's pre-built) will take 11m27s on my machine. After switching to VM anon classes it takes 10m30s.
            Show
            attila Attila Szegedi added a comment - Some performance results: running Octane suite for 2 iterations (excluding typescript and zlib as they're really slow) takes 276s on my machine; after switching to VM anon classes it takes 265s. Of that, 10s and 8s are spent installing classes, respectively. "ant test" (preceded by separate "ant jar" so everything's pre-built) will take 11m27s on my machine. After switching to VM anon classes it takes 10m30s.
            Hide
            attila Attila Szegedi added a comment -
            Implementation notes:

            The essential change is in Context.java, and a minor change in CompilationPhase.java where we use the new getMultiClassCodeInstaller API when needed.
            The old Context$ContextCodeInstaller class is now a base class for two subclasses, NamedContextCodeInstaller (embodying the old mechanism of loading classes as ordinary classes with resolvable names) and AnonymousContextCodeInstaller that uses Unsafe.defineAnonymousClass instead.

            NamedContextCodeInstaller is used if either persistent code cache or eager compilation features are on, otherwise AnonymousContextCodeInstaller is used. Further, AnonymousContextCodeInstaller gets substituted with a NamedContextCodeInstaller in case more than one class needs to be installed at once. (This can happen even with lazy compilation, e.g. when the compiled function contains a huge array literal.) This is needed as a set of classes resulting from a single compilation will reference each other by name, so they must be able to resolve each other's names; something they obviously can't do if they're anonymous VM classes.

            The functionality change is entirely isolated to Context.java - there's an if() statement in Context.compile() that switches between the two code installer classes.

            All changes in other classes are due to a bit of a cleanup in the CodeInstaller API, namely:
            - removing the type parameter from CodeInstaller, so it’s no longer CodeInstaller<T> – we only ever had CodeInstaller<ScriptEnvironment>
            - thus getOwner is now renamed to getScriptEnvironment
            - withNewLoader has been renamed to getOnDemandCompilationInstaller (its functionality didn’t change)
            Show
            attila Attila Szegedi added a comment - Implementation notes: The essential change is in Context.java, and a minor change in CompilationPhase.java where we use the new getMultiClassCodeInstaller API when needed. The old Context$ContextCodeInstaller class is now a base class for two subclasses, NamedContextCodeInstaller (embodying the old mechanism of loading classes as ordinary classes with resolvable names) and AnonymousContextCodeInstaller that uses Unsafe.defineAnonymousClass instead. NamedContextCodeInstaller is used if either persistent code cache or eager compilation features are on, otherwise AnonymousContextCodeInstaller is used. Further, AnonymousContextCodeInstaller gets substituted with a NamedContextCodeInstaller in case more than one class needs to be installed at once. (This can happen even with lazy compilation, e.g. when the compiled function contains a huge array literal.) This is needed as a set of classes resulting from a single compilation will reference each other by name, so they must be able to resolve each other's names; something they obviously can't do if they're anonymous VM classes. The functionality change is entirely isolated to Context.java - there's an if() statement in Context.compile() that switches between the two code installer classes. All changes in other classes are due to a bit of a cleanup in the CodeInstaller API, namely: - removing the type parameter from CodeInstaller, so it’s no longer CodeInstaller<T> – we only ever had CodeInstaller<ScriptEnvironment> - thus getOwner is now renamed to getScriptEnvironment - withNewLoader has been renamed to getOnDemandCompilationInstaller (its functionality didn’t change)
            Hide
            hgupdate HG Updates added a comment -
            URL: http://hg.openjdk.java.net/jdk9/dev/rev/5ee65c00794c
            User: attila
            Date: 2015-09-16 14:58:02 +0000
            Show
            hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/dev/rev/5ee65c00794c User: attila Date: 2015-09-16 14:58:02 +0000
            Hide
            hgupdate HG Updates added a comment -
            URL: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/79781ce06df7
            User: attila
            Date: 2015-09-16 16:34:18 +0000
            Show
            hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/79781ce06df7 User: attila Date: 2015-09-16 16:34:18 +0000
            Hide
            hgupdate HG Updates added a comment -
            URL: http://hg.openjdk.java.net/jdk9/jdk9/rev/5ee65c00794c
            User: lana
            Date: 2015-09-23 23:04:02 +0000
            Show
            hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/jdk9/rev/5ee65c00794c User: lana Date: 2015-09-23 23:04:02 +0000
            Hide
            hgupdate HG Updates added a comment -
            URL: http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/79781ce06df7
            User: lana
            Date: 2015-09-23 23:04:16 +0000
            Show
            hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/79781ce06df7 User: lana Date: 2015-09-23 23:04:16 +0000

              People

              • Assignee:
                attila Attila Szegedi
                Reporter:
                attila Attila Szegedi
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: