Memory layout benefits of inline classes

[Srikanth]

On 27/04/20 1:14 pm, 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?

Sorry for the delay in responding.

It is the aspirational plan to be able to migrate certain JDK classes 
that are "value based classes" today. Prominent among them is Optional. 
Not all issues about the migration of such classes are solved today, but 
it is in the works.
>
> 2. CompletableFuture: Similar to Optional, is this a candidate for
> potentially turning into an inline type?

JDK classes that are migration candidates are often tagged as being 
"value-based" classes in their javadoc. I don't see CompletableFuture 
being identified as such - I didn't verify whether CompletableFuture 
fails to meet the criterial for being a value based class (See 
https://docs.oracle.com/javase/8/docs/api/java/lang/doc-files/ValueBased.html) 


The short answer is: when we arrive at the bridge, we will take a call 
on what classes may be meaningfully, compatibly and profitably migrated.

Thus far I have heard of only Optional and various date and time related 
classes.

>
> 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?

Using your Id or Name classes as example, these instances could 
themselves be passed around as inline values - eliminating one level of 
pointer dereferencing (to reach the value reference). The string's 
content itself is going is (continue to involve) a level of dereferencing.

HTH,
Srikanth
>
> Regards
> Swaranga