Introduction

Value classes are the unification of two opposing concepts:

• the object-oriented paradigm, with dynamic dispatch
• the low-level paradigm, with flat data structures

As such, value classes behave like objects when interacting with object-oriented language features, while being represented similarly to C struct-s at the low level. Essentially, they are objects without their encapsulation: the data is separated from the code.

This brings a clear advantage -- giving up encapsulation allows "inlining" the class completely, thus eliminating the overhead of heap storage and dynamic dispatch. This can make significant differences in terms of performance. In particular, three elements contribute to the improved performance:

• avoiding object allocations, and thus garbage collection cycles
• reading values directly from the stack, not going through indirect pointer reads
• storing methods and transforming them to efficiently to pass and receive value classes

Let us take the following running example:

@value class Complex(val re: Double, val im: Double) {
  def + (c: Complex) = new Complex(re + c.re, im + c.im)
}

Executing the + operation between two complex numbers requires the existence of two different heap objects of type Complex and the allocation of a third one, the result. Furthermore, accessing re and im is done indirectly, via pointer+offset reads. For performance-oriented programs, the total overhead introduced is a no-go. So they resort to transforming such cases by hand.

Although not complex at first sight, replacing value classes by structures manually very is very difficult. Language features such as generics and nominal subtyping require the boxed representation, which needs to be encoded and extracted by hand. Interactions with overriding and subtyping require the introduction of bridge methods and finally synchronization needs to be taken into account. This makes the manual transformation almost impossible to get right in a general setting.

This is where the value class plugin saves the day: it automates all the tasks related to replacing value classes by their equivalent fields while maintaining semantics.

Still, there is a hard tension between object-orientation and breaking encapsulation, that manifests in two ways:

• lack of dynamic dispatch - breaking encapsulation makes it impossible to carry method information in the structure, thus forcing value classes to have final semantics;
• the interaction with generics and nominal subtyping requires the object-oriented representation. These make the transformation very tricky.

The next chapter will explain how the transformation handles these issues.