Thank you Christian! This looks very interesting indeed! I’ll read properly on the plane to JavaOne! I like the annotation based approach very much
/M On 23 Sep 2014, at 14:06, Christian Humer <[email protected]> wrote: > 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 <[email protected]> > Subject: Review request for JDK-8025435 > Date: 22 Sep 2014 16:38:48 GMT+2 > To: "[email protected] [email protected]" > <[email protected]> > > 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 > >
