Performance impact of decommissioning arrayStorageProperties to legacy code.
Tobias Hartmann
tobias.hartmann at oracle.com
Tue Jun 9 14:50:58 UTC 2020
Hi Sergey,
On 08.06.20 22:08, Sergey Kuksenko wrote:
> 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.
Okay, thanks for the details. Once we've implemented the mark word bit check, this needs to be
re-evaluated anyway.
> 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.
Makes sense.
> 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.
Yes, ideally we would have two bits. One for is-null-free and one for is-flat (which implies
is-null-free).
Best regards,
Tobias
More information about the valhalla-dev
mailing list