Waiting on intrinsic locks parks the executor thread

[Kasper Nielsen]

On Wed, 23 Jan 2019 at 14:42, Brian Goetz <brian.goetz at oracle.com> wrote:

> 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?
>

Would it be possible to only make locking semantics for value types
available via a vm option?
You could then throw something like
IllegalMonitorStateException("Synchronization on java.lang.Integer no
longer supported, run with --enableValueTypeLocking=enabled to enable
support")
You might even support just enabling some types such as "--enableLockingFor
java.base/java.lang.Integer"

Might even have the next couple of Java versions output a warning messages
"An illegal monitor operation on java.lang.Integer has occurred" . Similar
to the "An illegal reflective access operation has occurred" warnings that
people frequently see after having upgraded to Java 9. See the various
modes used for "--illegal-access" here
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/012673.html

Still not perfect, the application would still fail, but at least it would
be possible to run it again by adding the vm option. Also I assume there
must be some nice support contracts for those unnamed frameWorks. So I
assume a lot of people would never see it.

/Kasper