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

CallSite dependency tracking scales devastatingly poorly

    Details

    • Subcomponent:
    • Resolved In Build:
      b64

      Backports

        Description

        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)

          Attachments

            Issue Links

              Activity

                People

                • Assignee:
                  vlivanov Vladimir Ivanov
                  Reporter:
                  shade Aleksey Shipilev
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  6 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: