Agreed. And you can always transform the first situation into the second when you need to.
> On May 15, 2019, at 4:37 PM, Frederic Parain <[email protected]> > wrote: > > Here’s the basic question: how the JVM should handle the @Contended > annotation with respect to inline classes? > > Here’s some thoughts: > > First scenario: the @Contended annotation is used within an inline class: > > The @Contended annotation aims to solve the problem of false sharing, > but false sharing requires that the data in the cache are altered. Because > inline classes are immutable, no write operation can be performed on their > fields, > so no false sharing is possible between fields of a single inline class. > So there’s no point to change the layout of the inline class to put fields on > different cache lines. > > In addition to that, each use the @Contended adds 256 bytes to the size > of the instance (at least on the current HotSpot implementation), which is > well above the threshold we have considered reasonable so far to flatten > an inline classes instance. > > So the proposal would be to simply ignore @Contended when used > in an inline class. The javadoc of @Contended describes the annotation > as a hint to the JVM, so there’s no strict requirement to alter the layout > because of the annotation. > > Second scenario: A regular class has a field which is an inline class, and > this field is annotated with @Contended > > This use case still makes sense, to isolate this field (which could be > flattened or not) from other fields. This use of @Contended impacts > the layout of the container (the regular class) but not the layout of > the inline class. > > In this case, the JVM should use the hint to compute a layout isolating > the inline class field. > > Does this analysis make sense to you? Feedback and comments > are welcome. > > Regards, > > Fred > > >
