Review request for JDK-8025435

[Christian Humer]

Hi Marcus,

We have recently published a paper at GPCE on a systematic approach to
declare specializations for any kind of operations [1].
Some of the ideas that we've gathered there over the last two years might
also be applicable to your approach.

[1] http://lafo.ssw.uni-linz.ac.at/papers/2014_GPCE_TruffleDSL.pdf

- Christian Humer



*From: *Marcus Lagergren <marcus.lagergren at oracle.com>
> *Subject: **Review request for JDK-8025435*
> *Date: *22 Sep 2014 16:38:48 GMT+2
> *To: *"nashorn-dev at openjdk.java.net nashorn-dev at openjdk.java.net" <
> nashorn-dev at openjdk.java.net>
>
> Please review JDK-8025435 at
> http://cr.openjdk.java.net/~lagergren/8025435/
>
> https://bugs.openjdk.java.net/browse/JDK-8025435
>
> This is the framework for optimistic builtin functions. Summary of work
>
> * Introduced SpecializedFunction and SpecializedFunction.Guard for fast
> optimistic implementations
> * Modified ScriptFunction so that it picks the best specialization first,
> and checks if it can link using the above datastructures
> * Modified Nasgen to recognize the SpecializedFunction and its annotations
> * Implemented fast versions of Array.push/pop and String.charCodeAt as
> proof of concepts
> * Added a switchpoint based rather than guard based framework for
> invalidation of builtin functions (on a per context basis), to get rid of
> previous guard overhead
> * Added primitive linkage without proto filter as long as builtins acting
> upon them haven’t been rewritten
> * Currently there is support for invalidation of both entire builtins e.g.
> Array.prototype = something and proerties Array.prototype.push = something,
> but the granularity right now, to save switchpoints, uses the same
> switchpoint for an entire builtin and all its properties, as any other
> cases are rare. Granularity can easily be increased by adding keys to the
> builtinSwitchPoints table in the Context
> * Prefer to invalidate callsite by ClassCastException and failed type
> checks instead of explicit guards.
>
> I’m saving further specializations for later dates.
>
> Added various microbenchmarks to prove performance of the implementations
> of the current functions.
>
> Before patch:
>
> zann:make marcus$ sh ../bin/runopt.sh
> ../test/examples/push-pop-benchmark.js
> 18997 ms
>
> Verified OK - result is correct
>
> After patch:
>
> zann:make marcus$ sh ../bin/runopt.sh
> ../test/examples/push-pop-benchmark.js
> 2327 ms
>
> Verified OK - result is correct
> zann:make marcus$ d8 ../test/examples/push-pop-benchmark.js
> 9672 ms
>
> Verified OK - result is correct
>
> Similar benchmark exists for charCodeAt - my other proof of concept, which
> runs about 5x faster too.
>
> Test and test262 are clean after some horror corner cases with lengths and
> array like objects.
>
> Regards
> Marcus
>