On Sat, 16 Apr 2022 14:34:01 GMT, Alan Bateman <[email protected]> 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
