P4
Triggered by this ML discussion [1]
On Linux and BSD, we have a handshake between the creator thread and the newly created thread. Creator thread waits until the newborn thread is alive and reports back via a monitor handshake.
The newborn thread should avoid doing anything unnecessary before reporting back to the creator. But we added logging there, whose performance impact can be anything. We should defer logging to after that handshake.
Deferring logging - and then logging to a local file on a very fast ssd - reduces the runtime of the test the OP provided [1] by about 20%.
---
Side note: We don't do this handshake on AIX and Windows. Instead, there, we create the thread in suspended state and resume it later. Would be nice to get rid of that handshake for Linux too.
[1] https://mail.openjdk.java.net/pipermail/discuss/2021-May/005807.html
On Linux and BSD, we have a handshake between the creator thread and the newly created thread. Creator thread waits until the newborn thread is alive and reports back via a monitor handshake.
The newborn thread should avoid doing anything unnecessary before reporting back to the creator. But we added logging there, whose performance impact can be anything. We should defer logging to after that handshake.
Deferring logging - and then logging to a local file on a very fast ssd - reduces the runtime of the test the OP provided [1] by about 20%.
---
Side note: We don't do this handshake on AIX and Windows. Instead, there, we create the thread in suspended state and resume it later. Would be nice to get rid of that handshake for Linux too.
[1] https://mail.openjdk.java.net/pipermail/discuss/2021-May/005807.html
