Hi,
On Fri, 2013-07-12 at 19:22 +0800, Mandy Chung wrote:
Hi Thomas,
On 7/1/2013 7:51 PM, Thomas Schatzl wrote:
I changed this in
http://cr.openjdk.java.net/~tschatzl/8014890/webrev.refactor to that
version now, using a temporary variable that stores r.queue before the
checks to
Hi Thomas,
On 7/1/2013 7:51 PM, Thomas Schatzl wrote:
I changed this in
http://cr.openjdk.java.net/~tschatzl/8014890/webrev.refactor to that
version now, using a temporary variable that stores r.queue before the
checks to avoid the double volatile reads.
This looks good. I have pushed this
This looks fine to me.
Thanks,
David
On 1/07/2013 9:51 PM, Thomas Schatzl wrote:
Hi all,
On Mon, 2013-07-01 at 15:44 +0400, Aleksey Shipilev wrote:
On 07/01/2013 03:37 PM, David Holmes wrote:
On 1/07/2013 8:14 PM, Aleksey Shipilev wrote:
The same thou shalt not do multiple volatile reads
On 1/07/2013 9:44 PM, Aleksey Shipilev wrote:
On 07/01/2013 03:37 PM, David Holmes wrote:
On 1/07/2013 8:14 PM, Aleksey Shipilev wrote:
The same thou shalt not do multiple volatile reads applies to
(r.queue == NULL) || (r.queue == ENQUEUED) now.
Doesn't that just reduce to r.queue != this ?
Well you can ignore what I wrote below - sorry. Somehow I got it in my
head that multiple enqueue's were intended/supported when of course they
are not. :(
So the proposed fix is okay - though I'd simplify the comment to just:
// Check that since getting the lock this reference hasn't already
Hi David,
On Mon, 2013-07-01 at 17:51 +1000, David Holmes wrote:
Well you can ignore what I wrote below - sorry. Somehow I got it in my
head that multiple enqueue's were intended/supported when of course they
are not. :(
So the proposed fix is okay - though I'd simplify the comment to
On 07/01/2013 02:05 PM, Thomas Schatzl wrote:
Fyi, while waiting for your approval, I tried to clean up this a little
taking into account the comments from Peter and Aleksey (sorry if I
forgot somebody) into account.
Mandy Chung?
A webrev for this is at
On 1/07/2013 8:14 PM, Aleksey Shipilev wrote:
On 07/01/2013 02:05 PM, Thomas Schatzl wrote:
Fyi, while waiting for your approval, I tried to clean up this a little
taking into account the comments from Peter and Aleksey (sorry if I
forgot somebody) into account.
Mandy Chung?
A webrev for
On 07/01/2013 03:37 PM, David Holmes wrote:
On 1/07/2013 8:14 PM, Aleksey Shipilev wrote:
The same thou shalt not do multiple volatile reads applies to
(r.queue == NULL) || (r.queue == ENQUEUED) now.
Doesn't that just reduce to r.queue != this ? (The assert suggests
so :) )
Thomas'
Hi all,
On Mon, 2013-07-01 at 15:44 +0400, Aleksey Shipilev wrote:
On 07/01/2013 03:37 PM, David Holmes wrote:
On 1/07/2013 8:14 PM, Aleksey Shipilev wrote:
The same thou shalt not do multiple volatile reads applies to
(r.queue == NULL) || (r.queue == ENQUEUED) now.
Doesn't that just
On 07/01/2013 03:51 PM, Thomas Schatzl wrote:
Hi all,
On Mon, 2013-07-01 at 15:44 +0400, Aleksey Shipilev wrote:
On 07/01/2013 03:37 PM, David Holmes wrote:
On 1/07/2013 8:14 PM, Aleksey Shipilev wrote:
The same thou shalt not do multiple volatile reads applies to
(r.queue == NULL) ||
Hi Thomas,
Sorry for the delay in looking into this deeper but I've been OOTO a bit
this past week.
I'm backing up to the start to explore the apparent problem ...
On 19/06/2013 7:08 AM, Thomas Schatzl wrote:
Hi all,
can I have reviews for the following change?
It happens if multiple
Hi,
On Wed, 2013-06-19 at 12:47 +1000, David Holmes wrote:
Hi Thomas,
On 19/06/2013 7:08 AM, Thomas Schatzl wrote:
Hi all,
can I have reviews for the following change?
It happens if multiple threads are enqueuing and dequeuing reference
objects into a reference queue, that
Hi,
On Tue, 2013-06-18 at 15:53 -0700, Mandy Chung wrote:
Hi Thomas,
Thanks for the detailed analysis.
http://cr.openjdk.java.net/~tschatzl/8014890/webrev/
The fix looks good. I was able to reproduce the failure with the
test case in the bug report running with jdk8 b94 fastdebug
Hi again,
some correction...
On Wed, 2013-06-19 at 09:17 +0200, Thomas Schatzl wrote:
Hi,
On Wed, 2013-06-19 at 12:47 +1000, David Holmes wrote:
Hi Thomas,
On 19/06/2013 7:08 AM, Thomas Schatzl wrote:
Hi all,
can I have reviews for the following change?
It happens
Hi,
one more note :)
On Wed, 2013-06-19 at 09:28 +0200, Thomas Schatzl wrote:
Hi again,
some correction...
On Wed, 2013-06-19 at 09:17 +0200, Thomas Schatzl wrote:
Hi,
On Wed, 2013-06-19 at 12:47 +1000, David Holmes wrote:
Hi Thomas,
On 19/06/2013 7:08 AM, Thomas
On 06/19/2013 09:17 AM, Thomas Schatzl wrote:
Hi,
On Wed, 2013-06-19 at 12:47 +1000, David Holmes wrote:
Hi Thomas,
On 19/06/2013 7:08 AM, Thomas Schatzl wrote:
Hi all,
can I have reviews for the following change?
It happens if multiple threads are enqueuing and dequeuing reference
Hi Peter,
On Wed, 2013-06-19 at 11:05 +0200, Peter Levart wrote:
On 06/19/2013 09:17 AM, Thomas Schatzl wrote:
Hi,
On Wed, 2013-06-19 at 12:47 +1000, David Holmes wrote:
Hi Thomas,
On 19/06/2013 7:08 AM, Thomas Schatzl wrote:
Hi all,
can I have reviews for the following
Hi,
On Wed, 2013-06-19 at 09:25 +0200, Thomas Schatzl wrote:
Hi,
On Tue, 2013-06-18 at 15:53 -0700, Mandy Chung wrote:
Hi Thomas,
Thanks for the detailed analysis.
http://cr.openjdk.java.net/~tschatzl/8014890/webrev/
The fix looks good. I was able to reproduce the failure with
Hi Thomas,
I think I'm going to need a lot more time to understand this issue
completely. The synchronization being used seems complex and somewhat
ill-defined, and also inadequate. I'm not convinced that adding code
inside a synchronized block really fixes a race condition caused by
On 06/19/2013 04:05 PM, David Holmes wrote:
I think I'm going to need a lot more time to understand this issue
completely. The synchronization being used seems complex and
somewhat ill-defined, and also inadequate. I'm not convinced that
adding code inside a synchronized block really fixes a
Hi,
On Wed, 2013-06-19 at 17:56 +0400, Aleksey Shipilev wrote:
On 06/19/2013 04:05 PM, David Holmes wrote:
I think I'm going to need a lot more time to understand this issue
completely. The synchronization being used seems complex and
somewhat ill-defined, and also inadequate. I'm not
On 06/19/2013 06:09 PM, Thomas Schatzl wrote:
With that notion in mind, I start to wonder if we just need to move the
check in enqueue() down into the synchronized(lock), and extend it to
capture NULL:
--- a/src/share/classes/java/lang/ref/ReferenceQueue.javaMon Jun 17
16:28:22 2013
On 6/19/13 2:05 AM, Peter Levart wrote:
It doesn't make a difference between Reference.isEnqueued() and
ReferenceQueue.poll(), since there isn't any synchronization between
the two. So isEnqueued() can still be returning true while another
thread has already de-queued the instance. I guess
Hi all,
can I have reviews for the following change?
It happens if multiple threads are enqueuing and dequeuing reference
objects into a reference queue, that Reference objects may be enqueued
at multiple times.
This is because when java.lang.ref.ReferenceQueue.poll() returns and
inactivates
Hi Thomas,
Thanks for the detailed analysis.
http://cr.openjdk.java.net/~tschatzl/8014890/webrev/
The fix looks good. I was able to reproduce the failure with the
test case in the bug report running with jdk8 b94 fastdebug build.
But the new regression test doesn't fail (I tried
Hi Thomas,
On 19/06/2013 7:08 AM, Thomas Schatzl wrote:
Hi all,
can I have reviews for the following change?
It happens if multiple threads are enqueuing and dequeuing reference
objects into a reference queue, that Reference objects may be enqueued
at multiple times.
This is because when
27 matches
Mail list logo
