Value Types Optimization Dependencies

Karen Kinnear karen.kinnear at oracle.com
Thu Jun 14 17:35:30 UTC 2018



Value Types Optimization Dependencies

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

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.

Non-nullability/flattenability
	Some optimizations additionally require non-nullability which enables flattenability.
 	This could be thought of as container properties.

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.

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 important to have value types optimization re-enabled whenever possible; although not necessary to optimize for the null case. 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.

thanks,
Karen



More information about the valhalla-dev mailing list