RFR: 8329593: Drop adjustments to target parallelism when virtual threads do I/O on files opened for buffered I/O

[Jaikiran Pai]

On Wed, 3 Apr 2024 10:04:36 GMT, Alan Bateman <alanb at 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/java/lang/System.java line 2262:

> 2260:         @Override
> 2261:         public long transferTo(OutputStream out) throws IOException {
> 2262:             boolean attempted = Blocker.begin();

Hello Alan, why do we mark transferTo as potentially blocking operation which might need compensation? As far as I can see in the underlying implementation of `FileInputStream.transferTo()` it either calls the `FileChannel.transferTo()` or does a `in.read()` followed by `out.write()`. In either of those cases wouldn't the underlying `InputStream/OutputStream` already have the necessary `Blocker` calls?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18598#discussion_r1557679570