8222774: (ch) Replace uses of stateLock and blockingLock with explicit locks

[Martin Buchholz]

default void park(int event,

I would not have named a wait-for-network operation "park" - it's not
really related to LockSupport.park; there's no unpark operation.  The
phrase "unless the permit is available" looks like it was copied from the
park spec - does it really make sense here?   Is "event" really a single
event, or an "event set"?

---
"explicit locks"

Can you refer to these as j.u.c. locks (or perhaps simply ReentrantLock)
since even builtin locks are "explicit"?

---

I'm a little surprised at the pervasive conversion from builtin locks.  For
loom to succeed, you'll have to make builtin locks work eventually, eh?

History: back in 1.5, j.u.c. avoided builtin locks because ReentrantLock
used to be more efficient, and for dogfooding.  But it's hard to compete
with hotspot and so today the (rather weak) recommendation for users is to
use builtin locks unless the added flexibility or clarity of j.u.c. locks
is needed.

(of course, the deep support for builtin locks in hotspot is also the root
cause of loom conversion trouble)

---

(sorry, still not a network engineer)

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190423/7f227935/attachment.html>