3 ms·
> The situation with Object.wait() is not what JEP 444 calls "pinning". The "pinning" happens, for example, when one calls `syncronized(....) {blockingQueue.tak
by delusional 3y ago
> 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 3y agoAs 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 3y agoObject.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 3y agoThat makes sense to me. I'll agree to not call Object.wait() pinning.