Locking on primitive boxes

[Brian Goetz]

I received the following reply, which is worth reading into the record:

> Brian,
>
> Let me add my 5 cents here. My fear is that actually removing (making 
> private) constructors of primitive wrappers will break a lot of code 
> legacy code out there. In fact, even today we use those constructors 
> to work around limitations in HotSpot's escape analysis and allocation 
> elimination. E.g. if you conditionally return the result of 
> `Integer.valueOf(x)` from a method, then the allocation inside of the 
> valueOf cannot be eliminated by HotSpot (that allocation is 
> conditional itself and that is too much for HotSpot to see through), 
> but if, on the other hand, you conditionally return the result of `new 
> Integer(x)`, then HotSpot consistently eliminates this allocation.
>
> Sincerely,
> Roman Elizarov

It is notable that you bring up escape analysis here.  The hiding of the 
concrete constructors is something we are undertaking _precisely so we 
can migrate these wrappers to inline classes_; making them inline 
classes greatly improves the compiler's ability to eliminate 
allocations.  So I think this concern becomes "your grand plan, which 
has as a benefit greatly improved escape analysis, will interfere with 
my workarounds to get better escape analysis."

That said, it will take some time for existing uses to migrate away from 
these constructors -- all the more reason to deprecate them for removal 
earlier.


On 2/19/2020 11:45 AM, Brian Goetz wrote:
> 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.)
>
> 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, 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.
>
>
>