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
>> 
>> 
> 

Reply via email to