Memory layout benefits of inline classes

[Sergey Kuksenko]

Hi,

I would suggest to look into this talk 
http://cr.openjdk.java.net/~skuksenko/valhalla/talk/vp.pdf

I hope some ideas/examples expressed there could be useful.

In general there are the following key areas where performance benefits 
of inline types arises:

- local variables in tight loops (eliminate allocations)

- dense memory layout

- GC write barriers elimination (the most undervalued point, but may 
give a huge impact)

- maybe something else....

Straightforward candidates are:

- All kinds of arithmetic/numeric types (Complex, java.lang.Number, 
vectors, ...)

- Short-lived intra-invocation objects. Like multy-value methods 
results/arguments, CompositeKey, Optional. Set of values wrapped with 
some united logic and splitting them gives performance, but extracting 
as separate class improve readability, maintenance.

- Dense data-structures. Currently we don't have direct candidates from 
JDK classlib. Searching to be continued. For example B-tree(or B+-tree) 
implementation should have benefits. Someday I'll implement a prototype 
to prove it.

- Cursor as replacement of Iterator

- to be continued.


On 4/27/20 12:44 AM, Swaranga Sarma wrote:
> 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
> identifier.name().value() or identifier.id().value(). 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?
>
> Regards
> Swaranga