Waiting on intrinsic locks parks the executor thread

[Andrew Haley]

On 1/23/19 2:41 PM, Brian Goetz wrote:

> value classes are classes, and all classes extend Object.  (There is
> a several-thousand-hour debate on the pros and cons of this choice;
> please let’s not reproduce that here.)

> Surely there is legacy code in W-named monsters that locks on
> integers.  Yes, we know they shouldn’t.

For some reason I am reminded of my favourite comment, many years ago
(I think it was in PRIMOS) which said something like "The system clock
ticks at 14.2035 Hz because we always provide backwards compatibility,
no matter how ridiculous."

I'm amazed that works, given that Integer.valueOf(1) has only one
instance in the entire system. (And I note that to lock such an
instance violates the principle that Integers are immutable: to
lock an object is to mutate it!)

> So, Andrew: given that we made a mistake 22 years ago, do we depart
> from that mistake and create a category of non-lockable Objects, and
> when W* falls over, say “you shouldn’t have done that 20 years ago”,
> or, do we accept that we’re on the path we’re on, and find a way to
> define a not-totally-bogus locking semantics for value types,
> potentially at significant cost?

I think the answer depends on whether it's possible to define a
not-totally-bogus locking semantics for value types and what
consequences that might have for the integrity (not to mention sanity)
of rest of the language.

A (somewhat) obvious way to do it is to say that to be lockable a
value type must have a lock field which is a reference to an
Object. All attempts to synchronize on a value will delegate to its
lock, and it's the responsibility of the value's constructor to ensure
that the lock object exists and is unique. This would work everywhere
because it gives lockable values a proxy lock word and it means that
when you lock a value it only locks the one in your hand, not everyone
else's. This does no harm to the Java language at all, IMO.

But we really don't want to add a lock field to every instance of
Integer. Apart from anything else, it would mean that two instances of
Integer(1) might be unequal.

It is sort-of possible to do something like

   var n = Integer.uniqueLockableValueOf(3);

or somesuch, but ewww...  :-(

In GCJ we didn't have lock words: we had a lock-free hash map that
mapped objects onto locks. It's not at all impossible to do the same
thing with value types, but the semantics are vile because when you
lock, say, Integer(1) you lock everyone's Integer(1), everywhere.
That's no different from your legacy code in W-named monsters that
locks on integers, so perhaps people would put up with that behaviour,
but Yowza, it's horrible.

I think it's impossible to satisfy all of these requirements in a
reasonable way. Maybe someone who has spent longer than me thinking
about the problem has a nice way to do it...

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671