Waiting on intrinsic locks parks the executor thread

[Brian Goetz]

Andrew;

> In hindsight, allowing every
> object to be locked and signalled wasn't such a great idea.

As someone who holds this opinion, perhaps you’ll share your opinion on a related one.  (Others who have an opinion, please be polite and let Andrew answer first.)

Over in Valhalla, we’re cooking up Value Classes.  Value types are immutable aggregates that have no identity — just state.  Example:

    value class Complex {
       double re;
       double im;
    }

They are considered equal based on their state, not their identity (because they have none.)  But, 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.)   

So, a Complex is an Object, but it has no identity.  What should locking do when it encounters one?  

There are many possible options, but let’s restrict ourselves to two for now:

 - It throws IllegalMonitorStateException
 - It does something else

Let's stipulate that “all objects have locks” was a mistake.  But its still not clear what guidance this mistake gives us for subtypes of Object that do not have locks.  On the one hand, locking is an identity-sensitive operation, and values have no identity, so you could say locking one is silly, and throw.  That’s entirely justifiable.  On the other, we’ve got 22 years of training that says “all objects are lockable”, and even if that was a mistake, changing directions now might merely compound this mistake.  

I’m not actually concerned about code that tries to lock on something it knows to be a value type; I’m happy to exclude that at static compilation time.  I’m more worried about untyped data structures deep in the guts of legacy frameworks (some of whose names start with W), that do things like lock on the key of a map.  (Yes, we know they shouldn’t, but they do, and it’s “worked” for 20 years.)  

Similarly, I’m concerned about the ability to migrate the wrapper classes like java.lang.Integer to value types, which would have ENORMOUS benefit.  Surely there is legacy code in W-named monsters that locks on integers.  Yes, we know they shouldn’t.  

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?