Review request for JDK-8025435

Tue Sep 23 13:25:17 UTC 2014

Indeed. Richards is the most suspicious of my results, but it has a rather large standard deviation that has to do with in which order HotSpot picks candidates for inlining, so it is most likely noise - the standard deviation, is however larger than previous runs in any history I find on this machine. It is possible that subtle changes to some callsites have also affected performance. Not everything links the same and applies the guards in the same order anymore. I know that in the beginning I had tremendous regressions because of a castReference that sometimes slipped into the callsites (hence removed), so I’d seek the explanation there.

I also believe that there is a bug on HotSpot deterministic optimization behavior filed on Richards since before - on Roland if I remember correctly, and the cause is known. Basically we get different results between identical runs of the same binary from the same command line, because of non deterministic picks for initial optimization which affects inlining decisions.

I don’t have any official scores. This is just from my workstation. I’ll be back with more info later.

When it comes to warmup/startup, this change has no measurable impact. 

I’ll be back with more info when I’ve had this cleaned up and re-reviewed by the Nashorn committers. Some other issues have been pointed out to me during the day.

/M

On 23 Sep 2014, at 15:22, Thomas Wuerthinger <thomas.wuerthinger at oracle.com> wrote:

> 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 <marcus.lagergren at oracle.com> 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 <thomas.wuerthinger at oracle.com> 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 <marcus.lagergren at oracle.com> 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 <thomas.wuerthinger at oracle.com> 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 <marcus.lagergren at oracle.com> 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
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 