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

[Alan Bateman]

On Sat, 16 Apr 2022 10:25:56 GMT, Jaikiran Pai <jpai at openjdk.org> 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