Value Types Optimization Dependencies

[Karen Kinnear]

Resending - the matrix got flattened - must have thought it was a value type :-)

Goal of the exercise is to clarify which optimizations depend on which characteristics, in part to
understand the impact of null on optimizations.

Value Types Optimization Dependencies

Optimizations in the JVM runtime for Value Types depend on three different kinds of characteristics:

1. Type Information:
- Value Type vs. Identity Type

All the optimizations below depend on the static type information, specifically the key type properties of being identity-less and immutable.

It is important to ensure Value Type Consistency to enable these optimizations. This relies on disallowing value types to ever migrate to become identity types. Value-Based-Classes migrating to value types are a corner case which will require special handling.

2. Non-nullability/flattenability
Some optimizations additionally require non-nullability which enables flattenability.

This could be thought of as container properties.

3. Runtime dynamic information
Some optimizations additionally require dynamic information such as: is_flattened (is flattened in heap containers)

(requires flattenable, implementation-dependent) non-null (either non-nullable or dynamically non-null)

Optimization Dependencies Value Types

value type: identity-less & immutable

non-nullable flattenable

dynamic non-null

is_flattened

flattening in containers

required

required

N/A

Implementation- specific

scalarization invocation: input arguments

required

not required

i2c adapter null filter *1

not required

scalarization invocation: return

required

not required

caller check: if null, deopt

not required

scalarization field access

required

required

type check with null filter

required

scalarization inside method

required

not required

type check with null filter

not required

*1: Calling convention optimizations will require additional exploration. The Container Model proposal outlines some possibilities.

JIT optimizations have been destabilized with the introduction of the null reference for value types. Current implementation switches back to interpreted mode when a null reference to a value type is detected, it is primordial to have value types optimization re-enabled whenever possible. Considered explorations include:

• null profiling to scalarize only value types that are non-null most of the time • support for multiple nmethods
• use of a new non-null emotional type/carrier type to provide non-nullability

guarantees
New JIT optimizations might also be required to fully optimize the different kind of value arrays.