[9] RFR (M): 8057967: CallSite dependency tracking scales devastatingly poorly

[MacGregor, Duncan (GE Energy Management)]

Now I¹m back from my Easter break I¹ve run done some testing with our
code. Hs-comp is looking good in general, and this code does appear to
give a nice little extra boost. My results are showing a difference at
peak performance, which I found slightly surprising so I¹ll need to take a
look at just how often targets are being reset and for what reasons.

Anyway, in general I¹m getting about 10% better performance with hs-comp
than 8u40, and that¹s in code which spends a substantial amount of its
time down in some C libraries.

Keep up the good work Vladimir!

Duncan.

On 02/04/2015 17:26, "Vladimir Ivanov" <vladimir.x.ivanov at oracle.com>
wrote:

>Aleksey, thanks a lot for the performance evaluation of the fix!
>
>Best regards,
>Vladimir Ivanov
>
>On 4/2/15 7:10 PM, Aleksey Shipilev wrote:
>> On 04/01/2015 11:56 PM, Vladimir Ivanov wrote:
>>> http://cr.openjdk.java.net/~vlivanov/8057967/webrev.00/hotspot/
>>> http://cr.openjdk.java.net/~vlivanov/8057967/webrev.00/jdk/
>>> https://bugs.openjdk.java.net/browse/JDK-8057967
>>
>> Glad to see this finally addressed, thanks!
>>
>> I did not look through the code changes, but ran Octane on my
>> configuration. As expected, Typescript had improved substantially. Other
>> benchmarks are not affected much. This in line with the performance
>> analysis done for the original bug report.
>>
>> Baseline:
>>
>> Benchmark          Mode  Cnt        Score        Error  Units
>> Box2D.test           ss   20     4454.677 ±    345.807  ms/op
>> CodeLoad.test        ss   20     4784.299 ±    370.658  ms/op
>> Crypto.test          ss   20      878.395 ±     87.918  ms/op
>> DeltaBlue.test       ss   20      502.182 ±     52.362  ms/op
>> EarleyBoyer.test     ss   20     2250.508 ±    273.924  ms/op
>> Gbemu.test           ss   20     5893.102 ±    656.036  ms/op
>> Mandreel.test        ss   20     9323.484 ±    825.801  ms/op
>> NavierStokes.test    ss   20      657.608 ±     41.212  ms/op
>> PdfJS.test           ss   20     3829.534 ±    353.702  ms/op
>> Raytrace.test        ss   20     1202.826 ±    166.795  ms/op
>> Regexp.test          ss   20      156.782 ±     20.992  ms/op
>> Richards.test        ss   20      324.256 ±     35.874  ms/op
>> Splay.test           ss   20      179.660 ±     34.120  ms/op
>> Typescript.test      ss   20       40.537 ±      2.457   s/op
>>
>> Patched:
>>
>> Benchmark          Mode  Cnt        Score        Error  Units
>> Box2D.test           ss   20     4306.198 ±    376.030  ms/op
>> CodeLoad.test        ss   20     4881.635 ±    395.585  ms/op
>> Crypto.test          ss   20      823.551 ±    106.679  ms/op
>> DeltaBlue.test       ss   20      490.557 ±     41.705  ms/op
>> EarleyBoyer.test     ss   20     2299.763 ±    270.961  ms/op
>> Gbemu.test           ss   20     5612.868 ±    414.052  ms/op
>> Mandreel.test        ss   20     8616.735 ±    825.813  ms/op
>> NavierStokes.test    ss   20      640.722 ±     28.035  ms/op
>> PdfJS.test           ss   20     4139.396 ±    373.580  ms/op
>> Raytrace.test        ss   20     1227.632 ±    151.088  ms/op
>> Regexp.test          ss   20      169.246 ±     34.055  ms/op
>> Richards.test        ss   20      331.824 ±     32.706  ms/op
>> Splay.test           ss   20      168.479 ±     23.512  ms/op
>> Typescript.test      ss   20       31.181 ±      1.790   s/op
>>
>> The offending profile branch (Universe::flush_dependents_on) is also
>> gone, which explains the performance improvement.
>>
>> Thanks,
>> -Aleksey.
>>
>_______________________________________________
>mlvm-dev mailing list
>mlvm-dev at openjdk.java.net
>http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev