Running Nashorn/Octane benchmark with:

~/trunks/jdk9-dev/build/linux-x86_64-normal-server-release/images/j2sdk-image/bin/java -XX:+CITime -jar ~/trunks/jdk9-dev/build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/ext/nashorn.jar --class-cache-size=0 --persistent-code-cache=false -scripting --log=time test/script/basic/compile-octane.js -- --iterations 10

Yields the hotspot at:

7.365 jdk.nashorn.internal.runtime.linker.NashornLinker.getGuardedInvocation
2.992 jdk.nashorn.internal.runtime.ScriptObject.lookup
2.292 jdk.nashorn.internal.runtime.ScriptObject.findSetMethod
2.262 jdk.nashorn.internal.runtime.GlobalConstants.findSetMethod
1.601 jdk.internal.dynalink.DynamicLinker.getLinkedCallSiteLocation
1.601 java.lang.Throwable.getStackTrace

That is, out of 50 seconds of run, we spend 1.6 seconds doing Throwable.getStackTrace. This seems to be a part of diagnostic logging here:

    synchronized GuardedInvocation findSetMethod(final FindProperty find, final ScriptObject receiver, final GuardedInvocation inv, final CallSiteDescriptor desc, final LinkRequest request) {
       ...

        if (!acc.mayRetry()) {
            log.info("*** SET: Giving up on " + quote(name) + " - retry count has exceeded " + DynamicLinker.getLinkedCallSiteLocation());
            return null;
        }
   ...