Hi Shanliang,
The fix is good.
Just a side note...
I do not see why the line 98 is needed as no other thread is going to sync
on the DeadlockTest object (that is o) that is passed to the BadBoy
constructor:
98 synchronized(o) {
Thanks,
Serguei
On 12/11/14 11:33 PM, shanliang
Thank you, Daniel!
It is clear now.
Thanks,
Serguei
On 12/12/14 2:15 AM, Daniel Fuchs wrote:
On 12/12/14 10:11, serguei.spit...@oracle.com wrote:
Hi Shanliang,
The fix is good.
Just a side note...
I do not see why the line 98 is needed as no other thread is going to
sync
on the
On 1/7/16 08:40, Daniel Fuchs wrote:
Hi,
This looks OK to me.
I'm not sure I understand the full impact of the changes
in getAddressesForLocalHost() though - so hopefully someone
else will jump in to review that part...
Hi Jaroslav,
I do not understand the full impact of the getAddressesForLo
On 1/12/16 03:49, Jaroslav Bachorik wrote:
On 12.1.2016 11:47, serguei.spit...@oracle.com wrote:
On 1/7/16 08:40, Daniel Fuchs wrote:
Hi,
This looks OK to me.
I'm not sure I understand the full impact of the changes
in getAddressesForLocalHost() though - so hopefully someone
else will ju
On 1/13/16 03:16, Jaroslav Bachorik wrote:
On 12.1.2016 12:55, serguei.spit...@oracle.com wrote:
On 1/12/16 03:49, Jaroslav Bachorik wrote:
On 12.1.2016 11:47, serguei.spit...@oracle.com wrote:
On 1/7/16 08:40, Daniel Fuchs wrote:
Hi,
This looks OK to me.
I'm not sure I understand the
Hi Daniil,
+1
Thanks,
Serguei
On 5/20/19 23:20, David Holmes wrote:
Loosk good.
Thanks,
David
On 21/05/2019 1:25 pm, Daniil Titov wrote:
Please review un updated version of the previous change that also
removes unnecessary line
chmod ug+x $REVOKEALL
from
test/jdk/sun/management/jmxremo
Hi Daniil,
The fix has been applied cleanly.
LGTM++
Thanks,
Serguei
On 5/23/19 18:22, Daniil Titov wrote:
Please review the backport of this fix to JDK 12. The JDK 12 changes applied
mostly smoothly, but one hunk in make/test/JtregNativeJdk.gmk didn't apply
because of changed context lines.
new NotificationThread.
Webrev: https://cr.openjdk.java.net/~dtitov/8170299/webrev.02/
Bug: https://bugs.openjdk.java.net/browse/JDK-8170299
Thanks!
--Daniil
On 7/3/19, 9:02 PM, "serguei.spit...@oracle.com" wrote:
Hi Daniil,
I've not finished my review but it looks good
Best regards,
Daniil
From: "serguei.spit...@oracle.com"
Date: Monday, July 8, 2019 at 3:09 PM
To: Daniil Titov
, OpenJDK Serviceability
,
t;, in turns, includes "runtime/mutexLocker.hpp". Therefore, there is no need in having "
#include "runtime/mutexLocker.hpp" statement in "src/hotspot/share/runtime/notificationThread.cpp" file since the header file
"runtime/mutexLocker.hpp" is already
Hi Daniil,
Probably, it'd make sense to re-iterate on this after you resolve
David's comments.
Now, just one comment though as it looks dangerous.
http://cr.openjdk.java.net/~dtitov/8185005/webrev.03/src/hotspot/share/services/management.cpp.udiff.html
Hi Daniil,
Thank you for you patience in working on this issue!
Also, I like that the current thread related optimizations in
management.cpp were factored out.
It was a good idea to separate them.
I have a concern about the checks for thread->i
Hi David,
It is a nice catch!
I would suggest to rewrite this fragment in a safe way:
95 {
96 MutexLocker ml(ThreadTableCreate_lock);
97 if (!_is_initialized) {
98 create_table(threads->length());
99 _is_initia
Hi Daniil,
On 9/16/19 21:36, Daniil Titov wrote:
Hi David,
The case you have described is exact the reason why we still have a code inside
ThreadsList::find_JavaThread_from_java_tid() method that does a linear scan and
adds
the requested thread to the thread table if it is not there ( lines
On 18/09/2019 5:13 pm, serguei.spit...@oracle.com wrote:
Hi David,
On 9/17/19 03:46, David Holmes wrote:
Hi Serguei,
On 17/09/2019 7:10 pm, serguei.spit...@oracle.com wrote:
Hi Daniil,
On 9/16/19 21:36, Daniil Titov wrote:
Hi David,
The case you have described is exact the reason why we
ble
initialization.
David Holmes replied to this in a separate email providing a very detailed
explanation of the possible cases and how the proposed implementation satisfies
them.
Yes. Please, see above.
Thanks,
Serguei
Best regards,
Daniil
From: "serguei.spit...@oracle.com"
D
Hi David,
On 9/17/19 03:46, David Holmes wrote:
Hi
Serguei,
On 17/09/2019 7:10 pm, serguei.spit...@oracle.com wrote:
Hi Daniil,
On 9/16/19 21:36, Daniil Titov wrote
ier5 tests successfully passed.
Webrev: https://cr.openjdk.java.net/~dtitov/8185005/webrev.07/
Bug : https://bugs.openjdk.java.net/browse/JDK-8185005
Thank you!
--Daniil
On 9/18/19, 1:01 AM, "serguei.spit...@oracle.com" wrote:
Hi Daniil,
On 9/17/19 17:13, Dan
ank of ThreadTableCreate_lock.
So choosing between blocking new threads from starting and potentially allowing
some other monitoring thread to do a one-time linear scan I think it makes
sense to choose the latter.
Thanks!
Best regards,
Daniil
From: "serguei.spit...@oracle.com"
Hi Dan,
On 9/20/19 18:11, Daniel D. Daugherty wrote:
On 9/20/19 9:07 PM, Daniel D. Daugherty wrote:
On 9/20/19 7:15 PM, serguei.spit...@oracle.com wrote:
Hi Dan,
Please, find a minor correction below.
On 9/20/19 2:59 PM, Daniel D. Daugherty wrote:
Daniil,
Thanks for sticking with this
On 21/09/2019 9:50 am, serguei.spit...@oracle.com wrote:
Hi Daniil,
Yes, the Threads_lock is still needed around thread->is_exiting()
check and add_thread().
And if we try to use 2 locks, ThreadTableCreate_lock as in your snippet
and then the nested Threads_lock around thread->
Hi Dan,
On 9/20/19 18:11, Daniel D. Daugherty wrote:
On 9/20/19 9:07 PM, Daniel D. Daugherty wrote:
On 9/20/19 7:15 PM, serguei.spit...@oracle.com wrote:
Hi Dan,
Please, find a minor correction below.
On 9/20/19 2:59 PM, Daniel D. Daugherty wrote:
Daniil,
Thanks for sticking with this
ei,
On 21/09/2019 9:50 am, serguei.spit...@oracle.com wrote:
Hi Daniil,
Yes, the Threads_lock is still needed around thread->is_exiting()
check and add_thread().
And if we try to use 2 locks, ThreadTableCreate_lock as in your snippet
and then the nested Threads_lock around thread->
On 9/20/19 23:53, David Holmes wrote:
On 21/09/2019 4:21 pm, serguei.spit...@oracle.com wrote:
Hi David,
I do not want to insist in the area (Threads_lock use) where you have
much more expertise.
It's more conservatism than expertise :) I had a look through and
there are not too
= rem_n->next_ptr();
460 rem_n = rem_n->next();
461 }
462 }
463
464 bucket->unlock();
465
466 if (rem_n == NULL) {
467 return false;
468 }
Best regards,
Daniil
On 9/24/19, 11:35 AM, "serguei.spit...@oracle.com"
wrote:
On 9/27/19 11:06, Daniel D. Daugherty wrote:
On 9/27/19 1:58 PM, serguei.spit...@oracle.com wrote:
Hi Daniil,
Just notice I did not reply to you.
Thank you for the explanation!
Have you already pushed this one?
Pushed on 2019.09.25 at 1416 ET. It has made it thru Tier7 testing
as of
Hi Daniil,
+1
I also prefer (agree with) a new VM option to opt-out from the new behavior.
Sorry for some latency in the review and discussion process.
Thanks,
Serguei
On 10/1/19 20:20, David Holmes wrote:
Hi Daniil,
Thanks again for your perseverance with this one.
This looks fine to me.
Hi Daniil,
It is not a full review, just some minor comments.
In fact, I do not see real problems yet.
http://cr.openjdk.java.net/~dtitov/8226575/webrev.05/src/jdk.management/unix/classes/com/sun/management/internal/OperatingSystemImpl.java.frames.html
55 public long getTotalSwapSpaceSize
ns -1 if
something went wrong). But we could revise it in the follow
up issue I created for that [1].
[1] https://bugs.openjdk.java.net/browse/JDK-8235522
Thank you,
Daniil
On 12/9/19, 6:02 PM, "serguei.spit...@oracle.com"
wrote:
Hi Daniil,
It is not a full re
ds.
Thank you,
Daniil
On 12/11/19, 3:13 PM, "serguei.spit...@oracle.com"
wrote:
Hi Daniil,
One my concerns was a non-atomic read of multiple metrics before comparison.
It creates a potential to get a mismatch in result.
However, the probability to get a neg
30 matches
Mail list logo
