Locking on primitive boxes

[Remi Forax]

> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "valhalla-spec-experts" <valhalla-spec-experts at openjdk.java.net>
> Envoyé: Mercredi 19 Février 2020 17:45:38
> Objet: Locking on primitive boxes

> One of the main impediments to migrating the primitive wrappers to be the
> reference projection of an inline class is locking -- there may be code out
> there that locks on instances of primitive wrappers. Let's look at how we might
> wean users off, and what the compatibility constraints really are.

> First, note that all the wrappers have had static `valueOf()` factories, and the
> corresponding constructors have been deprecated since Java 9. It would be
> reasonable to deprecate these for removal at any time. (These would not
> actually be removed, but instead made private.)
You can make them synthetic instead of private, so there will not be available at compile time but still exist at runtime. 

> Having removed the public constructors, now the only way to get your hands on an
> Integer is through some mechanism like `valueOf()`. I claim now that:

> Under such a scheme, any code outside of java.lang that synchronizes on a
> wrapper is
> inherently broken

> That is, it is synchronizing on an object whose locking protocol you are not
> party to, which is not guaranteed non-aliased, and which may in fact be
> permanently locked by some other thread. Therefore, it is a forseeable outcome
> for such a sync attempt to block forever.

> This was the intent behind [ https://openjdk.java.net/jeps/169 |
> https://openjdk.java.net/jeps/169 ] , though it wasn't obvious from the title
> -- the ability to mark certain objects as permanently locked.

> So, concrete proposal:

> - Move forward with the deprecation-for-removal of the constructors;

> - Add hortatory notes in the spec for `valueOf()` that locking on objects whose
> provenance you do not control is a risky business, and may well never complete;

> - Poison instances of primitive wrappers by marking their headers at creation
> with a bit pattern that will send locking through the slow path, where it can
> see that these are poisoned objects and cause lock attempts to never complete
> (or throw)

> - Provide a JDK-scoped option to turn off the above behavior
> (-Xx:AllowStupidBrokenLockingOnPrimitiveWrappers)

> I don't see anything stopping us from doing any of these immediately.
I still think it's a bit early, i would prefer to have reified generics before deciding how to retrofit primitive wrapper, i.e. if we can still have two different behavior, box and value, from the same class. 

That said, i agree with what is proposed here (with synthetic instead of private), there is no point to continue to allow people to shoot themselves in the foot with synchonizing on wrapper types. 

Rémi