@Contended and inline classes

Brian Goetz brian.goetz at oracle.com
Wed May 15 20:44:41 UTC 2019

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 <frederic.parain at oracle.com> 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

More information about the valhalla-spec-experts mailing list