Performance impact of decommissioning arrayStorageProperties to legacy code.

[Tobias Hartmann]

Hi Sergey,

thanks a lot for the detailed analysis!

On 06.06.20 09:30, Sergey Kuksenko wrote:
>   - 16 benchmarks got speedup (v-66 -> v-72) typically around +5% (some up to +10%)

Good. I guess that's due to negative impact that clearing the property bits had on klass loads.

>   - 14 benchmarks got degradation (v-66 -> v-72) typically around -5% (some -10%)

Are these microbenchmarks or larger ones? I would expect that we only see regressions in tight loops
with array accesses.

>   From one side having the fact that it's typical for Valhalla changes cause benchmarks jittering
> within 10%, we are not consider performance changes less than 10% as significant
>   (this threshold will be lowered with Valhalla maturity). From the other side 10% of benchmarks
> (from the selected set) degrade with Valhalla, that means we can't leave it as is
>   and should solve it sooner or later, otherwise there is a high chance of negative acceptance by
> Java community.

Yes, I agree.

>          3. In general performance regressions of Valhalla checks caused by 3 reasons:
>       - Increased amount of instructions. More work (checks) has to be done.
>       - Complex tags and masks. Having non single bit mask is not an issue itself. But it always
> spoils a register. And causes more and more register spilling (as avalanche) and may crash
> performance of tight
>      sensitive loop. Particularity that induced register spilling is the source of regression. I
> will advocate for the single bit masks as much as possible. As for layout helper tag -
>      3 values for 8 bits - more than enough>        By the way: We don't have CMS anymore. Biased locking is going away. Markword became simpler.
> Could we find a one bit in markwork to mark inline type object?
>         - More memory loads and cache misses. Unavoidable. The only way - to make better and better
> out of loop hoisting and checks elimination.
Yes, I think that's what we should do.

One bit in the mark word would allow us to improve the is-flat check for aaload but not the
is-null-free check required for aastore. Do you have any sense if that is good enough?

Best regards,
Tobias