Axel, I’ve created a bug to track. May be slow to process because of vacations and JDK9 long march.
https://bugs.openjdk.java.net/browse/JDK-8164477 Cheers, — Jim > On Aug 19, 2016, at 11:41 AM, Axel Faust <axel.faus...@googlemail.com> wrote: > > Hello, > > in my ongoing project to implement an alternative scripting integration to > the ECM platform Alfresco using Nashorn, I recently ran into a performance > issue due to constructor / function recompilation due to type > specialization, particularly if the constructor / function in question is > accessing the "arguments" object. > > I have tried to simplify this with a test and used "jjs > --log=recompile:finest" to run it. > > Consider the following script: > > function testArguments() { print(JSON.stringify(arguments)); } > // simple call tests > testArguments('test1'); // first access => 2x "parameter type > specialization" > testArguments('test1'); // identical parameter => no recompilation > testArguments('test2'); // identical param type, different value => > "parameter type specialization" > testArguments('test3'); // identical param type, different value => > "parameter type specialization" > // iterative call test > for (var i = 0; i < 1000; i++) { testArguments('test' + i); } // identical > param type, different values => only one "parameter type specialization" > > > Now I don't quite understand why script function "testArguments" needs to > be recompiled on each call with the same parameter type but different > value, and how this is not required when executed within a loop structure. > The latter is interesting on another level, since a test script for my > Alfresco-Nashorn integration is running an array-forEach loop where the > called function is being recompiled on every iteration, while replacing the > for-loop in the test script above with an array-forEach (pre-filled) > behaves exactly the same as the for-loop with only a single recompilation. > Additionally, in the integration test script I even see recompilations for > identical values (in subsequent runs of the same script). > > Now having a single recompilation wouldn't be so bad, but continous > recompilation hurts quite a bit. Unfortunately this affects quite a central > piece in my integration project and thus causes significant overhead via > ClassLoader.defineClass, Class.getDeclaredFields and method handle / call > site handling operations that result from the recompilation. Each run of my > integration-specific test script adds ~10 CompiledFunction instances to the > ScriptFunctionData.code list for the same function (all with apparently > identical call site types and invokers, at least judging from > toString-representations). The persistent code cache doesn't seem to be > used at all as RecompilableScriptFunctionData.getBest calls > compileTypeSpecialization in a way that disables its use. > > Is this behaviour something that should be considered "expected" or is it a > "real" performance bug? If it is expected, is there a general > recommendation not to use functions that access arguments for > performance-critical code? > (I tested with JDK 8u71 and JDK 9 ea+125 - behaviour is the same except JDK > 9 provides deoptimization log output on 1st call) > > Regards > Axel Faust
