Re: RFR(S): 8073042: jcmd hangs until another jcmd is executed (which, in turn, also hangs) (on Windows)

2015-03-02 Thread Dean Long
Couldn't you instead treat it like a monitor? Then it's OK if only the first notify wakes up the blocked thread, as long as that thread only blocks when the queue is empty. In other words, when it wakes up, it should process all the items in the queue before blocking again. dl On 3/2/2015 4:3

Re: RFR(XS) for PeriodicTask_lock cleanup (8072439)

2015-03-02 Thread Daniel D. Daugherty
Thanks! Dan On 3/2/15 8:02 AM, Coleen Phillimore wrote: Yes, this new comment tells me the secret bit of information I didn't know from looking at that bit of code. thanks, Coleen On 2/27/15, 4:54 PM, Daniel D. Daugherty wrote: Coleen and David, My final attempt to get more acceptable w

Re: RFR(XS) for PeriodicTask_lock cleanup (8072439)

2015-03-02 Thread Daniel D. Daugherty
On 3/2/15 1:27 AM, David Holmes wrote: On 28/02/2015 7:54 AM, Daniel D. Daugherty wrote: Coleen and David, My final attempt to get more acceptable wording for this comment: Here's the current wording: +// The WatcherThread is not a JavaThread so we do not honor the +// safepoint proto

RE: RFR(S): 8073042: jcmd hangs until another jcmd is executed (which, in turn, also hangs) (on Windows)

2015-03-02 Thread Markus Gronlund
Hi Jaroslav, Thanks for taking a look. "So, if the number of enqueue request is higher than the max semaphore count it will just fail with the assert?" I am letting the max semaphore count reflect the number of available (also pre-allocated) operations - a client should not be able to reach th

RE: RFR(S): 8073042: jcmd hangs until another jcmd is executed (which, in turn, also hangs) (on Windows)

2015-03-02 Thread Markus Gronlund
Hi Dmitry, Thanks for taking a look. Also thanks for the hint about using a guarantee instead of an assert - you are right, I will change it accordingly. Cheers Markus -Original Message- From: Dmitry Samersoff Sent: den 2 mars 2015 14:52 To: Markus Gronlund; serviceability-dev@openjd

Re: RFR(XS) for PeriodicTask_lock cleanup (8072439)

2015-03-02 Thread Coleen Phillimore
Yes, this new comment tells me the secret bit of information I didn't know from looking at that bit of code. thanks, Coleen On 2/27/15, 4:54 PM, Daniel D. Daugherty wrote: Coleen and David, My final attempt to get more acceptable wording for this comment: Here's the current wording: +

Re: RFR(S): 8073042: jcmd hangs until another jcmd is executed (which, in turn, also hangs) (on Windows)

2015-03-02 Thread Dmitry Samersoff
Markus, Looks good for me. Excellent finding. Variable 229 BOOL not_exceeding_semaphore_maximum_count = is not used in production and it could lead to a compiler warning. So it might be better to use guarantee instead of assert here. -Dmitry On 2015-03-02 15:34, Markus Gronlund wrote: >

Re: RFR(S): 8073042: jcmd hangs until another jcmd is executed (which, in turn, also hangs) (on Windows)

2015-03-02 Thread Jaroslav Bachorik
Hi Markus, On 2.3.2015 13:34, Markus Gronlund wrote: Greetings, Kindly asking for reviews for the following changeset: Bug: https://bugs.openjdk.java.net/browse/JDK-8073042 Webrev: http://cr.openjdk.java.net/~mgronlun/8073042/webrev01/ Looks reasonable. Description: The signaling mechan

RFR(S): 8073042: jcmd hangs until another jcmd is executed (which, in turn, also hangs) (on Windows)

2015-03-02 Thread Markus Gronlund
Greetings, Kindly asking for reviews for the following changeset: Bug: https://bugs.openjdk.java.net/browse/JDK-8073042 Webrev: http://cr.openjdk.java.net/~mgronlun/8073042/webrev01/ Description: The signaling mechanism used to communicate about attaching operations under Windows c

Re: RFR(XS) for PeriodicTask_lock cleanup (8072439)

2015-03-02 Thread David Holmes
On 28/02/2015 7:54 AM, Daniel D. Daugherty wrote: Coleen and David, My final attempt to get more acceptable wording for this comment: Here's the current wording: +// The WatcherThread is not a JavaThread so we do not honor the +// safepoint protocol for the PeriodicTask_lock. Mut