RFR: 8284161: Implementation of Virtual Threads (Preview) [v3]

[Jaikiran Pai]

On Sat, 16 Apr 2022 14:34:01 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/misc/Blocker.java line 76:
>> 
>>> 74:                 && currentCarrierThread() instanceof CarrierThread ct && !ct.inBlocking()) {
>>> 75:             ct.beginBlocking();
>>> 76:             long comp = ForkJoinPools.beginCompensatedBlock(ct.getPool());
>> 
>> It appears that `ForkJoinPools.beginCompensatedBlock(...)` can throw an exception. Would such an exception require the CarrierThread's blocking state (which we set on the previous line) to be reset by a call to `ct.endBlocking()`? Or is it futile to reset that state if any exception gets thrown from the call to `ForkJoinPools.beginCompensatedBlock(...)`?
>
> REE isn't possible here but maybe you mean a resource issues such as stack overflow or OOME. If that happens then the flag wouldn't be reset. It wouldn't a correctness issue but we may be able to make this a bit more robust for these cases.

Hello Alan, 
My concern wasn't really about OOME or resource issue. I had noticed the `ForkJoinPools.beginCompensatedBlock` has a try/catch which then propagates back the `Throwable`. So I thought there could be some genuine exceptions that could be thrown in this flow which ultimately calls `ForkJoinPool.beginCompensatedBlock()`. I haven't yet reached the changes in `ForkJoinPool.java` class itself, so it's likely that this catch block is only there for theoretical reasons when dealing with `MethodHandle`.

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

PR: https://git.openjdk.java.net/jdk/pull/8166