Topics

Featured in Development

As part of our core values of sharing knowledge, the InfoQ editors were keen to capture and share our book and article recommendations for 2018, so that others can benefit from this too. In this second part we are sharing the final batch of recommendations

Featured in Architecture & Design

Tanya Reilly discusses her research into how the fire code evolved in New York and draws on some of the parallels she sees in software. Along the way, she discusses what it means to be an SRE, what effective aspects of the role might look like, and her opinions on what we as an industry should be doing to prevent disasters.

Featured in Culture & Methods

Mik Kersten has published a book, Project to Product, in which he describes a framework for delivering products in the age of software. Drawing on research and experience with many organisations across a wide range of industries, he presents the Flow Framework™ as a way for organisations to adapt their product delivery to the speed of the market.

Featured in DevOps

The fact that machine learning development focuses on hyperparameter tuning and data pipelines does not mean that we need to reinvent the wheel or look for a completely new way. According to Thiago de Faria, DevOps lays a strong foundation: culture change to support experimentation, continuous evaluation, sharing, abstraction layers, observability, and working in products and services.

Design of Java Value Types Makes Progress

Project Valhalla with OpenJDK has posted a major update and has announced some initial, very early-stage design concepts for value types in the JVM.

The overall mission statement of the project is to be "a venue to explore and incubate advanced Java VM and Language feature candidates". Brian Goetz explains the major goals of the project as:

Align JVM memory layout behavior with the cost model of modern hardware

Extend generics to allow abstraction over all types, including primitives, values, and even void

Enable existing libraries especially the JDK to compatibly evolve to fully take advantage of these features.

Up to and including version 9, Java only has two sorts of values - primitive types, and object references. To put this another way, the Java environment deliberately does not provide low-level control over memory layout. As a special case, this means that Java has no such thing as structs, and any composite data type can only be accessed by reference.

This memory layout pattern has been the way that major implementations of the Java platform have functioned for the last 20 years. It has the advantage of great simplicity, but comes with a number of performance tradeoffs - such as the fact that dealing with arrays of objects involves unavoidable indirections and attendant cache misses.

As a result, many performance-oriented programmers would like the ability to define types that can be laid out in memory more efficiency - value types.

These new types would also reduce overhead by removing the need for a full object header for each item of composite data. Removal of the object header would also remove the instance-specific metadata that all current Java objects have.

One consequence of this is that the object's identity would be lost, and values would be equal if and only if all their fields are equal. This would make values behave similarly to the primitive types - each copy of the value 42 does not have its own identity after all.

To accommodate this major change, some new bytecodes will need to be introduced, but currently it is believed that only two new opcodes would need to be added:

vdefault which produces the default instance of a given value class

withfield which produces a new value of a value type (and throws on a non-value)

Some existing bytecodes will also need some retrofitting to handle value types.

Above the VM level, work is also needed to allow the core libraries to evolve in a compatible manner - as it will now be necessary e.g. to have a method to test an Object variable to see if it actually contains a value object.

Beyond this simple conception of value types are some immediate further design questions. For example, whether value types can be used as type parameter values for generic types.

If not, then this would seem to greatly limit the usefulness of value types. Therefore, the design discussion of values types has always included the assumption that they will be valid as values of type parameters in an as-yet-unspecified enhanced form of generics.

Ongoing research in Project Valhalla has led to the following early stage design concept: That there should be three different kinds of JVM class and interface types at VM level:

Reference types that represent references to an instance of a class that has an identity (or is null)

Value types - that hold an instance of a value class that lacks identity

Universal types - that can be either of the other two types

This raises the obvious question - "How should type information in existing class files be understood?"

That is, are the existing current object types in Java 9 class files actually considered to be reference types, or are they really universal types and it's simply the case that we've never seen an instance of a value class before?

The current design is still in the very early stages and is only a proposal that will not be fully baked for months, and may be years away from production readiness and shipping code.

Due to the changes to the release schedule, it is completely unknown which release of Java will eventually feature value types as a production feature.

The discussion and research continues on the Project Valhalla mailing lists, and readers who are comfortable with VM internals should start there for more details, with the understanding that the current work is a long way from being usable by most developers and is only at the prototyping stage.