Thank you Mandy for review!
On 30.03.2014 8:20, Mandy Chung wrote:
On 3/27/2014 6:36 AM, Ivan Gerasimov wrote:
Now, I updated the webrev with the additional delay as you suggested:
http://cr.openjdk.java.net/~igerasim/8038333/2/webrev/
Thanks for the updated patch, Ivan and also Peter for the
On 3/27/2014 6:36 AM, Ivan Gerasimov wrote:
Now, I updated the webrev with the additional delay as you suggested:
http://cr.openjdk.java.net/~igerasim/8038333/2/webrev/
Thanks for the updated patch, Ivan and also Peter for the suggestion to
delay to give a chance for the threads to wait on the
On 27.03.2014 18:00, Peter Levart wrote:
On 03/27/2014 02:36 PM, Ivan Gerasimov wrote:
Thank you Peter!
There could be a little delay (say half the timeout: 500ms)
specified after main thread returns from the startedSignal.await();
and before setting referent = null; and doing System.gc(). T
On 03/27/2014 02:36 PM, Ivan Gerasimov wrote:
Thank you Peter!
There could be a little delay (say half the timeout: 500ms) specified
after main thread returns from the startedSignal.await(); and before
setting referent = null; and doing System.gc(). This would decrease
the chance that the ref
Thank you Peter!
There could be a little delay (say half the timeout: 500ms) specified
after main thread returns from the startedSignal.await(); and before
setting referent = null; and doing System.gc(). This would decrease
the chance that the reference is enqueued before EarlyTimeout threads
Hi Ivan,
On 03/27/2014 08:26 AM, Ivan Gerasimov wrote:
David, Mandy, thank you for comments!
Here's what we want to achieve in the test:
Two EarlyTimeout child threads should both be blocked in
remove(TIMEOUT) at the moment the weakReference gets enqueued.
This is the situation, when the bug
David, Mandy, thank you for comments!
Here's what we want to achieve in the test:
Two EarlyTimeout child threads should both be blocked in remove(TIMEOUT)
at the moment the weakReference gets enqueued.
This is the situation, when the bug 6853696 manifests itself.
If we made sure the weakRefere
On 3/26/2014 3:57 PM, David Holmes wrote:
Ivan,
I think the problem is that the EarlyTimeout threads can complete
their remove(TIMEOUT) before the main thread has started them all,
cleared the reference and called System.gc().
Depending on exactly what is being tested, the EarlyTimeout threa
Ivan,
I think the problem is that the EarlyTimeout threads can complete their
remove(TIMEOUT) before the main thread has started them all, cleared the
reference and called System.gc().
Depending on exactly what is being tested, the EarlyTimeout threads may
need to wait on another latch that
Thank you Mandy!
Are you able to reproduce the test failure?
Yes, I could easily reproduce the failure when I reduced the timeout to
10 ms.
With the timeout reduced, the test fails every third time on my machine.
I think the test verifies that only one thread gets the reference is a
good t
Hi Ivan,
On 3/26/2014 6:15 AM, Ivan Gerasimov wrote:
Hello!
The test java/lang/ref/EarlyTimeout.java, which has been recently
added to the repository with the fix for 6853696 has failed.
The error message of the failure "more than one references were
removed from queue" seems to be misguiding
11 matches
Mail list logo
