Author jeff.allen
Recipients darjus, jamesmudd, jeff.allen, stefan.richthofer, zyasoft
Date 2017-08-05.12:19:50
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
After backing out (on a scratch repo only, so far) the sets and, in the interests of #2609, I ought to find I've re-instated this issue.

Is there a sure-fire way to reproduce it?

However, I'm not sure the original problem these change sets sought to solve is what we think ... The synchronisation on PyType looks ok[1] to me, even though the two locks seem to have got entangled, according to the informative thread dump from Darjus.

In that, "Jython-Netty-Child-60" is doing a reasonable thing. It has entered the monitor on PyType.class and is patiently waiting here:,
to acquire the lock on the class_to_type map.

"MainThread" meanwhile is waiting to enter the monitor on PyType.class (good), but is holding the lock on on the class_to_type map (huh?). This ought not to be possible, since the monitor protects access to the class_to_type map. It looks like somehow, "MainThread" has previously exited the monitor still holding the lock.

We've a nice explanation of how that can happen in #2536.


[1] Actually, there *is* one place class_to_type map escapes synchronisation, and that's here:
I think that's an oversight. And it's not involved here.
Date User Action Args
2017-08-05 12:19:52jeff.allensetmessageid: <>
2017-08-05 12:19:52jeff.allensetrecipients: + jeff.allen, zyasoft, darjus, stefan.richthofer, jamesmudd
2017-08-05 12:19:52jeff.allenlinkissue2487 messages
2017-08-05 12:19:50jeff.allencreate