Versions Compared

Old Version 3

changes.mady.by.user David Simms

Saved on

compared with

New Version Current

changes.mady.by.user David Simms

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Welcome to the L-World Value Types early adopter's project !

Table of Contents

What are Inline Types?

  • Formerly known as "Value Types", renamed "inline-types" (discussion here)
  • Inline Types are small, immutable, identity-less types
  • User model: "codes like a class, works like an int"
  • Use cases: Numerics, algebraic data types, tuples, cursors, ...
  • Removing identity commitment enables optimizations such as
    • flattening of inline types in containers such as fields or arrays
      • reducing cost of indirection and locality of reference with attendant cache miss penalties
      • reducing memory footprint and load on garbage collectors
  • Combining Immutability and no identity commitment allows inline types to be stored in registers or stack or passed by value

What is the L-World

...

project?

The L-World

...

project is a series of early prototypes for

...

bring Inline Types to the language and JDK.

    • Value
      • Inline Types contained in References, other
    • Value
      • Inline Types or in Arrays are flatten-able
    • Value Types
      • Inline Types can contain primitives or references
  • Allows value types to inter-operate with Object or "L-Type" descriptors

Target Audience

  • Power users  - Java/JVM Language, Framework, Library authors/exports
    • who are comfortable with early experimental software
    • who recognize that everything in the experiment - the model, the classfile extensions, the byte codes is likely to change
    • who want to contribute to early exploration of Value Types
    • who will not build any products based on these prototypes
  • Who are willing to provide feedback to the developers on a subset of Value Type features
  • Who will provide use cases for the development team to experiment with optimizations

"L-World"

...

      • JVMS class file model for MVT: 
        • Separate descriptors to distinguish inline types from object types using "Q" signatures (Q-Types) similar to how Object descriptors begin with "L"

...

        • (L-Types

...

        • ).
        • Separate bytecodes, starting with "v", called "v-bytecodes" to distinguish from reference "a-bytecodes".
    • MVT limitations:
      • No direct support for methods
      • No compatibility with existing Objects and Interfaces
    • Enabled exploration of  potential maximum optimizations for inline types with minimal impact on existing objects (object identity types)

"L-World"

To maximize backward compatibility with existing Objects and interfaces, i.e. existing L-Types, the current prototype incorporates inline types into the L-Type system or "L-World".

  • Inline Value Types may be referred to by the same "L-Type" descriptors the VM has always operated on:
    • May implement interfaces with inline types
    • May may pass a vale inline type as an object, a java.lang.Object, or an interface through existing APIs
  • Inline Type characteristics:
    • immutable: unmodifiable instance fields
      • may contain primitives, other inline types, references to mutable objects
      may implement interfaces with value types
    • identity-less: 
      • synchronization will including use of wait(*), notify*()  will fail with exception: IllegalMonitorStateException
      • reference equality with "==" (if_acmp<eq|ne>) always returns false, value equality requires using the "equals()" methodperforms a substitutability test, comparing each field (much like carry out "equals()")
      • freely substitutable when equal, no visible change in behavior if equals()
    • final
  • JVMS class file model for "LWorld"
    • Re-uses "L" descriptors
    • Re-uses "a-bytecodes"
    • There are only two new byte-codes, otherwise existing byte-codes have been engineered to accept and maintain
    value
    • inline type characteristics (identity-less,
    flattened
    • flattenable, pass by value):
      • "
      default
      • defaultvalue" - will create a new default
      value
      • inline type
      • "withfield"- allows updating
      value
      • inline type fields via a copy-on-write semantic, i.e. new value based on the old value combined with new field value.

Recognize that the path to Valhalla is long, there are number of open issues facing value inline types. We wish to solve these incrementally. Fully generic specialization of value inline types with clear and sensible migration rules are going to take more than a single prototype.

Prototypes

...

...

  • Experimental source support with "__ByValue" class declaration modifier
  • Value Types cannot be used as parameterized types, i.e. current generic type declarations do not support primitives, nor value types at this point in time
  • Type migration, including partial recompilation is not support at this point

How to Try L-World Value Types:

Early Access Binaries

http://jdk.java.net/valhalla/

Repository and Build Instructions

To create a new local repository, based on "lworld" branch:

hg clone http://hg.openjdk.java.net/valhalla/valhalla valhalla-lworld

cd valhalla-lworld

hg defpath du <openjdkname> 

hg update -r lworld // name of branch

To update repository: 

cd valhalla-lworld

hg pull

hg update -r lworld  // name of branch

To build repository

bash configure

make images

 

Instructions for working with branch repositories: http://cr.openjdk.java.net/~chegar/docs/sandbox.html

Note: Valhalla is a child of the jdk/jdk repository, to keep current with latest OpenJDK development.

Programming Model

CMH: Example code

Run Experimental L-World

  • java -XX:+EnableValhalla <Test>
  • CMH: further flags (both javac and java)

Filing Bugs

Limitations

  • platforms: x64 Linux, x64 Mac OS X, Windows
  • no support for atomic fields containing value types (work-in-progress for an update)
  • no CDS, redefineclasses
  • -Xint and C2 only, no C1, no tiered-compilation
  • interpreter is not optimized, focus is on JIT optimization
  • Need additional USE CASES for optimizations
  • Working on additional test cases

References