Performance impact of decommissioning arrayStorageProperties to legacy code.
sergey.kuksenko at oracle.com
Mon Jun 8 20:08:44 UTC 2020
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
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,
More information about the valhalla-dev