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