[delusional]

> The situation with Object.wait() is not what JEP 444 calls "pinning". The "pinning" happens, for example, when one calls `syncronized(....) {blockingQueue.take()}` [...]

To call Object.wait() you need to own the objects monitor, which would imply that your code would actually look like `synchronized(....) {Object.wait()}` in which case you would indeed be pinned.

[avodonosov]

As I read JEP 444 (starting from the quote above and several following paragraphs, ending with the words "As always, strive to keep locking policies simple and clear."), the term "pinning" is when a blocking function, that normally unmounts virtual thread, does not do so, due to being called from `synchronized` or from native code.

That's different from blocking functions, described in the quote, that does not even try to unmount virtual thread. Like Object.wait().

Pinning is worse than those functions, because the functions compensate for a blocked native thread by adding one more native thread to the pool.

[xmcqdpt2]

Object.wait() releases the monitor lock though. This specific case doesn't have to do with synchronized at all, but with wait() being a native call.

[delusional]

That makes sense to me. I'll agree to not call Object.wait() pinning.