Review request for JDK-8007060

Jim Laskey (Oracle) james.laskey at oracle.com
Thu Jan 31 09:21:14 PST 2013


+1

On 2013-01-31, at 12:42 PM, Hannes Wallnoefer <hannes.wallnoefer at oracle.com> wrote:

> I did some octane testing with this patch today and didn't note any performance degradations. I also noticed that only one octane test uses non-builtin methods on primitives at all, and that is earley-boyer.
> 
> Based on this I uploaded a slightly changed patch to http://cr.openjdk.java.net/~hannesw/8007060/:
> 
> 1) Adding the wrapFilter is now a one-way, i.e. once added it stays there and also handles object this-arguments (it did that already anyway). This makes NonStrictFunctionGuard simpler because we only have to check whether this-argument is ScriptObject (we install an ordinary FunctionGuard when the wrap filter is used).
> 
> 2) I moved primitive wrapping from ScriptRuntime.apply() to ScriptFunction.invoke(). It really belongs there and also makes related code a bit nicer.
> 
> Hannes
> 
> Am 2013-01-30 14:20, schrieb Hannes Wallnoefer:
>> Please review http://cr.openjdk.java.net/~hannesw/8007060/
>> 
>> This removes the NashornInvocationTarget class whose purpose was to track primitiveness of callsite targets and replaces it in two ways.
>> 
>> 1) For functions invoked via ScriptRuntime.apply() (this includes ordinary megamorphic callsites) we simply check function strictness and this-argument primitiveness at runtime. We should have done that anyway, I think there were several uses of this method that forgot to wrap primitives when they should have.
>> 
>> 2) For ordinary monomorphic callsites we check function strictness and this-argument primitiveness at link time. If this is primitive we install a wrapper methodhandle as argument filter. We then use a new NonStrictFunctionGuard that in addition to the FunctionGuard check tests whether primitiveness of this-argument has changed by doing one simple instanceof check. (This should be very rare, as invocation of script functions on JS primitives should generally be rare.
>> 
>> I've tested this with test, test262parallel, and octane. Haven't tested node.jar yet. Haven't done any in-depth performance tests but I think there should be no notable regression.
>> 
>> thanks,
>> Hannes
> 



More information about the nashorn-dev mailing list