Richards does not seem to use these functions. I’d expect deltablue to be the 
main benchmark to be affected. Do you have scores available? Is there an impact 
on warmup/startup performance of the changes on these benchmarks?

I fully trust that there are some regulations in place. We can help with peer 
review.

- thomas

On 23 Sep 2014, at 15:05, Marcus Lagergren <[email protected]> wrote:

> Octane - Yes. I’ve only specialized 3 functions, but there are mesurable 
> increases in crypto, deltablue, richards, earley-boyer and regexp, which all 
> to some extent use these function. Nothing world beating, but definitely 
> 10-15% on some of them even after compensating from standard deviation. 
> Nothing else seems to have regressed. 
> 
> When it comes to the release process, trust me, it’s well regulated and 
> extremely peer reviewed. 
> 
> /M
> 
> On 23 Sep 2014, at 13:25, Thomas Wuerthinger <[email protected]> 
> wrote:
> 
>> 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
>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 

Reply via email to