Hi Jaroslav,
On 2015-08-27 17:03, Jaroslav Bachorik wrote:
Hi Claes,
On 27.8.2015 16:42, Claes Redestad wrote:
Updated webrev after comments and discussion with Jaroslav:
http://cr.openjdk.java.net/~redestad/jdk9/8134583/webrev.03
Changes:
- convert 'threads' from array to list
- simplified
Hi,
One more pair of eyes on this. 8^)
On 8/27/2015 8:16 PM, Kim Barrett wrote:
On Aug 27, 2015, at 5:42 PM, Daniel D. Daugherty
wrote:
Sorry for starting another e-mail thread fork in an already complicated
review...
OK, that was fascinating. No, really, I mean it.
It made me realize tha
On 8/27/15 6:16 PM, Kim Barrett wrote:
On Aug 27, 2015, at 5:42 PM, Daniel D. Daugherty
wrote:
Sorry for starting another e-mail thread fork in an already complicated
review...
OK, that was fascinating. No, really, I mean it.
:-)
It made me realize that we've been arguing and talking pa
On 8/28/15 8:45 AM, Tom Benson wrote:
Hi,
One more pair of eyes on this. 8^)
Hi Tom!
Thanks for reviewing and welcome to the party...
On 8/27/2015 8:16 PM, Kim Barrett wrote:
On Aug 27, 2015, at 5:42 PM, Daniel D. Daugherty
wrote:
Sorry for starting another e-mail thread fork in an alr
Hi Dan,
On 8/28/2015 12:27 PM, Daniel D. Daugherty wrote:
On 8/28/15 8:45 AM, Tom Benson wrote:
Hi,
One more pair of eyes on this. 8^)
Hi Tom!
Thanks for reviewing and welcome to the party...
On 8/27/2015 8:16 PM, Kim Barrett wrote:
On Aug 27, 2015, at 5:42 PM, Daniel D. Daugherty
wro
On 8/28/15 11:57 AM, Tom Benson wrote:
Hi Dan,
On 8/28/2015 12:27 PM, Daniel D. Daugherty wrote:
On 8/28/15 8:45 AM, Tom Benson wrote:
Hi,
One more pair of eyes on this. 8^)
Hi Tom!
Thanks for reviewing and welcome to the party...
On 8/27/2015 8:16 PM, Kim Barrett wrote:
On Aug 27, 201
Hi Dan,
On 8/28/2015 2:12 PM, Daniel D. Daugherty wrote:
. . .
Not easily in ReenterI(), the OM_PERFDATA_OP(FutileWakeups, inc()) call
is at the bottom of the for-loop and the OrderAccess::fence() call at
the end of the function is outside the loop. This would result in lost
FutileWakeups in
On Aug 28, 2015, at 11:52 AM, Daniel D. Daugherty
wrote:
>
> This comment:
>
> 570 // Keep a tally of the # of futile wakeups.
> 571 // Note that the counter is not protected by a lock or updated by
> atomics.
> 572 // That is by design - we trade "lossy" counters which ar
Hi again,
Just noticed I skipped this question in your reply:
So in ReenterI() the OM_PERFDATA_OP(FutileWakeups, inc()) call
immediately
follows an OrderAccess::fence() call. Doesn't that make that increment as
"safe" as it can be without having a real lock?
Yes - odd that I noticed the fen
On 8/28/15 12:27 PM, Kim Barrett wrote:
On Aug 28, 2015, at 11:52 AM, Daniel D. Daugherty
wrote:
This comment:
570 // Keep a tally of the # of futile wakeups.
571 // Note that the counter is not protected by a lock or updated by
atomics.
572 // That is by design - we
On 8/28/15 12:24 PM, Tom Benson wrote:
Hi Dan,
On 8/28/2015 2:12 PM, Daniel D. Daugherty wrote:
. . .
Not easily in ReenterI(), the OM_PERFDATA_OP(FutileWakeups, inc())
call
is at the bottom of the for-loop and the OrderAccess::fence() call at
the end of the function is outside the loop.
On 8/28/15 12:29 PM, Tom Benson wrote:
Hi again,
Just noticed I skipped this question in your reply:
So in ReenterI() the OM_PERFDATA_OP(FutileWakeups, inc()) call
immediately
follows an OrderAccess::fence() call. Doesn't that make that
increment as
"safe" as it can be without having a real
12 matches
Mail list logo
