Memory layout benefits of inline classes

Zheka Kozlov orionllmain at gmail.com
Tue May 5 07:17:18 UTC 2020


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;


вт, 5 мая 2020 г., 12:37 Srikanth <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().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
>
>


More information about the valhalla-dev mailing list