Yes, very agile. So the plan is to push these 2k LOC right before 8u40 feature completeness deadline? Did you see any impact on the Octane benchmarks?
- thomas On 23 Sep 2014, at 08:07, Marcus Lagergren <[email protected]> wrote: > Thomas, > > I just checked in a few benchmarks that I’ve used for development for now. > Harnesses come later. I just want to get the framework for optimistic > builtins into the product before I do anything else, like adding more > specializations and formal benchmarks for it. This is more of a “help > remember this” note far, to keep the code around so I remember testing it > when I do changes. We’ve done it like this before - turning “examples” stuff > into part of the benchmark suite to check for regressions. > > Incremental. Agile. Short deadlines. Whatever ;) > > We will definitely put stuff that crop out of this in a more formal benchmark > harness later. > > /M > > On 22 Sep 2014, at 20:25, Thomas Wuerthinger <[email protected]> > wrote: > >> Aleksey, >> >> I was wondering about your comments on "test/examples/push-pop-benchmark.js” >> - already thinking about jsmh ;) ? >> >> - thomas >> >> >> On 22 Sep 2014, at 16:38, Marcus Lagergren <[email protected]> >> wrote: >> >>> 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 >>> >>> >> >
