Memory layout benefits of inline classes

[Srikanth]

On 05/05/20 12:47 pm, Zheka Kozlov wrote:
> Can you please explain how can Optional become an inline class if 
> inline classes are non-nullable? Doesn't it mean that every code like 
> this will throw NPE after migration?
>
> Optional<String> opt = null;

Please study: 
https://cr.openjdk.java.net/~briangoetz/valhalla/sov/02-object-model.html
for the evolving design.

Srikanth

<https://cr.openjdk.java.net/~briangoetz/valhalla/sov/02-object-model.html>
>
>
> вт, 5 мая 2020 г., 12:37 Srikanth <srikanth.adayapalam at oracle.com 
> <mailto:srikanth.adayapalam at oracle.com>>:
>
>
>
>     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 <http://identifier.name>().value() or
>     identifier.id <http://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
>