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 >
