On Wed, 3 Apr 2024 10:04:36 GMT, Alan Bateman <al...@openjdk.org> wrote:
> This change drops the adjustments to the virtual thread scheduler's target > parallelism when virtual threads do file operations on files that are opened > for buffered I/O. These operations are usually just too short to have any > benefit and may have a negative benefit when reading/writing a small number > of bytes. There is no change for read/write operations on files opened for > direct I/O or when writing to files that are opened with options for > synchronized I/O file integrity (O_SYNC/O_DSYNC and equivalents). Sergery > Kuksenko is polishing benchmarks that includes this area, this is for a > future PR. > > In addition, the blocker mechanism is updated to handle reentrancy as can > happen if debugging code is added to ForkJoinPool, if there is preemption > when attempting to compensate, or potentially forced preemption in the > future. This part is a pre-requisite to the changes to better support object > monitor there are more places where preemption is possible and this quickly > leads to unbalanced begin/end. > > The changes have been baking in the loom repo for several months. src/java.base/share/classes/jdk/internal/misc/Blocker.java line 79: > 77: * Marks the beginning of a possibly blocking operation. > 78: * @param blocking true if the operation may block, otherwise false > 79: * @return true if tryCompensate attempted Was the use the word `tryCompensate` intentional here? I don't see that method in this class or in the implementation of `CarrierThread.beginBlocking()` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18598#discussion_r1557805449
