RFR(L): 8024070: C2 needs some form of type speculation

[Vladimir Kozlov]

Roland,

Thank you for doing this experiment. But Richards is faster ;)
Regression could be also caused by different inlining (InlineSmallCode) 
because more uncommon traps are generated.
Anyway, you convince me. Let me go through your changes again. I am also 
looking on your extra type profiling changes.

Thanks,
Vladimir

On 9/6/13 11:16 AM, Roland Westrelin wrote:
>>> Can you try an other experiment (may be you did it already)? Always (under flag) generate klass check (type_check_receiver()) when unique type from profiling is more precise than type from static analysis. Yes, we may get performance regression in cases where more precise type is not needed. We need to test it and see how bad it is.
>>
>> This change in itself doesn't bring any performance improvement. It's here so that if we add more profiling points (8023657) we know what to do with the data from profiling. Type speculation + extra profiling show a perf improvement on nashorn (10-20% on some benchmarks with the nashorn.jar from jdk b105). To me the experiment that makes sense it to enable profiling from 8023657, do the type checks at the profiling points systematically and see what impact we see on perf. I did that with type checks on entry to the root method of the compilation for incoming arguments and at returns from calls that were not inlined and I had a clear regression on specjvm98. I don't remember the exact numbers. I can run the experiment again.
>
> This is the kind of results I get with nashorn:
> deltablue:
> current: 2345
> with type speculation and extra profiling: 2662
> with extra profiling and systematic type checks: 2285
>
> RayTrace:
> current: 1978
> with type speculation and extra profiling: 2113
> with extra profiling and systematic type checks: 1795
>
> Richards:
> current: 2222
> with type speculation and extra profiling: 2489
> with extra profiling and systematic type checks: 2563
>
> "extra profiling and systematic type checks" is:
> - type checks for incoming arguments on method entry for the root method of the compilation
> - type check on return from non inlined calls
>
> so a limited subset of type checks but that gives us type for value flowing in the compiled method. Eventhought the number of checks is limited, it is sufficient to cause a regression on standard benchmarks:
>
> ============================================================================
> t
>    Benchmark         Samples        Mean     Stdev
>    specjvm98              10      663.84      0.01
>      javac                10      385.70      0.05
>      db                   10      444.51      0.01
>      jess                 10      699.05      0.00
>      jack                 10      603.98      0.01
>      compress             10      534.99      0.01
>      mtrt                 10     1694.45      0.01
>      mpegaudio            10      866.77      0.00
> ============================================================================
> t2
>    Benchmark         Samples        Mean     Stdev   %Diff    P   Significant
>    specjvm98              10      654.39      0.01   -1.42 0.014            *
>      javac                10      356.46      0.07   -7.58 0.013            *
>      db                   10      444.87      0.01    0.08 0.875            *
>      jess                 10      681.66      0.01   -2.49 0.000          Yes
>      jack                 10      601.90      0.01   -0.34 0.425            *
>      compress             10      538.06      0.02    0.57 0.329            *
>      mtrt                 10     1722.77      0.03    1.67 0.181            *
>      mpegaudio            10      854.38      0.01   -1.43 0.001          Yes
> ============================================================================
>
> Roland.
>