On Sat, 16 Apr 2022 10:25:56 GMT, Jaikiran Pai <[email protected]> wrote:
>> Alan Bateman has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains five additional
>> commits since the last revision:
>>
>> - Refresh
>> - Refresh
>> - Merge with jdk-19+18
>> - Refresh
>> - Initial push
>
> 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 corrects issue but we may be able to make this a bit more robust for these
cases.
-------------
PR: https://git.openjdk.java.net/jdk/pull/8166
