BT

Your opinion matters! Please fill in the InfoQ Survey!

Oracle Presents First Proposal for Value Types Implementation

| by Abraham Marín Pérez Follow 6 Followers on Nov 09, 2016. Estimated reading time: 3 minutes |

A couple of months ago, Oracle JVM architect John Rose, and Oracle Java language architect Brian Goetz, published the first minimal value type proposal. Value types will provide developers with the capability to define new types that share some of the semantics of primitives. The objective of this initial proposal is simply to allow prototyping, experimentation, and the production of the first micro-benchmarks; since the final version is not expected until Java 10, the proposal adds only one new bytecode instruction to support value types, and defers any Java language changes for a future version.

Since the Java language itself is not being modified as part of this proposal, the only way to make use of the new features will be directly through the relevant bytecode constructs. This means that only developers who work on bytecode generation tools, such as JVM language developers, will have access to value types. On top of this, the value types capabilities will only be available for classes denoted and constructed to that effect, which are loaded into specific value-capable modules, and which are present in class files of a specific major and minor version. This heavily sandboxed approach ensures that advanced users can access the new capabilities, while ordinary users can still use the new versions of the JVM without stumbling upon issues.

The full set of changes to support this first version of value types can be found on the proposal but can be summarised in the following four items:

  • A new annotation called @DeriveValueType to tell the JVM about value-capable types. It's important to distinguish here between value-types and value-capable types. Value-capable types are ordinary Java classes that the JVM can use to generate a value type. If value types are not enabled, then the value-capable type is just an ordinary class.
  • Extension of the class file format to add the definition of a new Q-Type descriptor. The current class file format defines type signatures with a letter, including both primitives (I for integer, C for character, etc) and what is called an L-Type for objects (L followed by the fully qualified name of the class, like "Ljava/lang/String;"). The Q-Type will work in a similar way to an L-Type, but it will be specific to value-types (and its descriptor will start with the letter Q).
  • One new bytecode instruction, called "typed", to move Q-Types to and from the stack. The new instruction will work as a kind of macro-instruction, meaning it can be combined with other existing instructions to create the effect of multiple new bytecodes being available. This approach will provide "typed" with two parameters: an index pointing to the definition of the Q-Type, so the JVM knows what it needs to load or store, and another bytecode, indicating the operation to be executed. This is similar to the current "wide" operator.
  • A new class called ValueType<T> with methods to execute reflection operations on Q-Types; this will be analogous to the existing Class<T> for ordinary types. This is particularly important because, in order to reduce the number of new bytecode instructions to a bare minimum, there will be no instructions, at least for now, to create or manipulate Q-Types. Providing reflection capabilities means these operations can still be done through the relevant method handle, but without committing to a new bytecode instruction.

This proposal is far from a full implementation, and its experimental nature suggests that it will differ from the final version; as the authors themselves highlighted, there is always the chance that none of these items will be part of the final release. However, this early version will allow prototyping with Project Panama or GPU experiments, which will provide feedback regarding performance, development effort for a full solution, and usability. As an example, one of the things that are expected to be discovered with this activity, is the final set of bytecode instructions that should be added to the JVM to fully support value types.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Great stuff by Ciprian Khlud

Java is close to a perf-king in many areas, but high memory usage and cache misses were making quick code to be hard to be achieved.

Value types should make many things to simply work, especially a more compact HashMap, making easier to make sens of immutable programming without throwing trash on GC.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

1 Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT