Performance impact of decommissioning arrayStorageProperties to legacy code.

[Sergey Kuksenko]

On 6/8/20 12:52 AM, Tobias Hartmann 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.
Yes. And now I think it's good idea don't mix bits into klass pointer. 
Otherwise we have to clear klass pointer every time, even when we may 
prove that no inline classes exists in the system.
>>    - 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.

Both kinds. Some standard benchmarks has tight loops. Anyway, digging 
through these benchmarks will be time consuming. I won't do it until we 
have what do in area of small microbenchmarks. I've shown it for overall 
picture.

I am doing another overview of large benchmarks. Now I may only say that 
from 40 large (relatively) benchmarks only 3 have regression in 
Valhalla. Let's wait other results, maybe I'll be able to make 
differentiation aaload/aastore from acmp. Don't know yet.

> 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?

I didn't check aastore yet.

But general thoughts. I'd rather split our performance goals into 3 areas:

1. Legacy code with legacy types.

2. Legacy code with inline types.

3. Inline code with inline types.

And the number 1 is the most important (in my opinion). Because of 
nobody want to get regression just starting to use new JDK version. In 
that case 1 bit is enough for aastore. 1 bit is telling that "there is 
something from valhalla" and it will go to slowpath and won't affect 
legacy performance. Case 2 of course needs more bits.





>
> Best regards,
> Tobias