Memory layout benefits of inline classes

Swaranga Sarma sarma.swaranga at
Mon Apr 27 07:44:44 UTC 2020

The examples of the benefits of inline classes that I have seen in demos
are things like high allocation of data classes in a tight loop. I was
trying to understand how some of our existing code may benefit by using
inline classes which is different from the examples seen. I have the
following questions:

1. Optional: If we have a nullable members in a class, we would like to
return an Optional<T> in the accessor for that member unless we have a
reason to reduce the allocation. I recall somewhere that Optional might be
an inline type in the future and this concern may no longer be valid. Is my
understanding correct?

2. CompletableFuture: Similar to Optional, is this a candidate for
potentially turning into an inline type?

3. Regular data classes: In a lot of our code bases, we have data classes
that look like:
class Identifier {
  final @NonNull Name name;
  final @NonNull Id id;

class Name {
  final @NonNull String value;

class Id {
  final @NonNull String value;

We create instances like these and pass these around to other methods.
Those methods access the necessary values using the access methods like or These classes are
probably good candidates for migrating to records. But I was also
interested to understand if we also made them inline classes what memory
layout benefits would we get. Would the pointer de-referencing problem go
away in such cases?

To put it in another way, most of our data classes boil down to Strings,
and assuming String will not become an inline type, would there be any
memory-layout benefits of making such classes inline?


More information about the valhalla-dev mailing list