On Thu, 29 Aug 2024 17:06:19 GMT, Andrey Turbanov wrote:
>> My suspicion is that Condition::await() throws before having successfully
>> reacquired the lock, and this exception is swallowed because Lock::unlock()
>> then throws when invoke with an IllegalMonitorStateException as the current
>>
On Thu, 15 Aug 2024 18:22:54 GMT, Viktor Klang wrote:
> My suspicion is that Condition::await() throws before having successfully
> reacquired the lock, and this exception is swallowed because Lock::unlock()
> then throws when invoke with an IllegalMonitorStateException as the current
> thread
On Thu, 15 Aug 2024 18:22:54 GMT, Viktor Klang wrote:
> My suspicion is that Condition::await() throws before having successfully
> reacquired the lock, and this exception is swallowed because Lock::unlock()
> then throws when invoke with an IllegalMonitorStateException as the current
> thread
On Thu, 15 Aug 2024 21:05:39 GMT, Viktor Klang wrote:
>> src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedLongSynchronizer.java
>> line 290:
>>
>>> 288: acquire(node, arg, false, false, false, 0L);
>>> 289: break;
>>> 290: } catch
On Tue, 20 Aug 2024 11:53:20 GMT, Alan Bateman wrote:
>> One option is to record the first encountered exception instance, which can
>> then be rethrown once acquire succeeds?
>
> Object.wait and Condition.await are unusual in that they must reacquire they
> continue, even if they throw. So mig
On Thu, 15 Aug 2024 19:02:38 GMT, Viktor Klang wrote:
>> My suspicion is that Condition::await() throws before having successfully
>> reacquired the lock, and this exception is swallowed because Lock::unlock()
>> then throws when invoke with an IllegalMonitorStateException as the current
>> th
My suspicion is that Condition::await() throws before having successfully
reacquired the lock, and this exception is swallowed because Lock::unlock()
then throws when invoke with an IllegalMonitorStateException as the current
thread was not reestablished as the owner.
So this PR is intended to
On Fri, 16 Aug 2024 09:51:43 GMT, Alan Bateman wrote:
>> @DougLea @AlanBateman This seems to fix TestDisposerRace.java
>
>> @DougLea @AlanBateman This seems to fix TestDisposerRace.java
>
> That test runs with a small heap so I assume it's OOME. I can't help thinking
> we need to back off with
On Thu, 15 Aug 2024 18:22:54 GMT, Viktor Klang wrote:
> My suspicion is that Condition::await() throws before having successfully
> reacquired the lock, and this exception is swallowed because Lock::unlock()
> then throws when invoke with an IllegalMonitorStateException as the current
> thread
On Fri, 16 Aug 2024 09:06:48 GMT, Viktor Klang wrote:
> @DougLea @AlanBateman This seems to fix TestDisposerRace.java
That test runs with a small heap so I assume it's OOME. I can't help thinking
we need to back off with a timed-Unsafe.park before retrying.
> src/java.base/share/classes/java/u
10 matches
Mail list logo
