From daniil.x.titov at oracle.com Thu Jul 4 03:04:26 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Wed, 03 Jul 2019 20:04:26 -0700 Subject: jmx-dev RFR: 8170299: Debugger does not stop inside the low memory notifications code Message-ID: <75B5F778-DC49-494B-AC12-270F301677CA@oracle.com> Please review the change the fixes the problem with the debugger not stopping in the low memory notification code. The problem here is that the ServiceThread that calls these MXBean listeners is hidden from the external view that prevents the debugger from stopping in it. The fix introduces new NotificationThread that is visible to the external view and offloads the ServiceThread from sending low memory and other notifications that could result in Java calls ( GC and diagnostic commands notifications) by moving these activities in this new NotificationThread. Testing: Mach5 tier1,tier2 and tier3 tests succeeded. Webrev: https://cr.openjdk.java.net/~dtitov/8170299/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8170299 Thanks! --Daniil From serguei.spitsyn at oracle.com Thu Jul 4 04:02:36 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 3 Jul 2019 21:02:36 -0700 Subject: jmx-dev RFR: 8170299: Debugger does not stop inside the low memory notifications code In-Reply-To: <75B5F778-DC49-494B-AC12-270F301677CA@oracle.com> References: <75B5F778-DC49-494B-AC12-270F301677CA@oracle.com> Message-ID: <30fa7fad-92c7-c6a2-9c73-84265cc02208@oracle.com> Hi Daniil, I've not finished my review but it looks good in general. A couple of quick comments. https://cr.openjdk.java.net/~dtitov/8170299/webrev.01/src/hotspot/share/runtime/notificationThread.hpp.html ?I wonder if this function is also needed: ?? static bool is_notification_thread(Thread* thread); https://cr.openjdk.java.net/~dtitov/8170299/webrev.01/src/hotspot/share/runtime/notificationThread.cpp.html I wonder why this include statement is missed: ? #include "runtime/mutexLocker.hpp" Also, these have to be correctly ordred: 29 #include "runtime/notificationThread.hpp" 30 #include "services/lowMemoryDetector.hpp" 31 #include "services/gcNotifier.hpp" 32 #include "services/diagnosticArgument.hpp" 33 #include "services/diagnosticFramework.hpp" Thanks, Serguei On 7/3/19 8:04 PM, Daniil Titov wrote: > Please review the change the fixes the problem with the debugger not stopping in the low memory notification code. > > The problem here is that the ServiceThread that calls these MXBean listeners is hidden from the external view that prevents the debugger from stopping in it. > > The fix introduces new NotificationThread that is visible to the external view and offloads the ServiceThread from sending low memory and other notifications that could result in Java calls ( GC and diagnostic commands notifications) by moving these activities in this new NotificationThread. > > Testing: Mach5 tier1,tier2 and tier3 tests succeeded. > > Webrev: https://cr.openjdk.java.net/~dtitov/8170299/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8170299 > > Thanks! > --Daniil > > From david.holmes at oracle.com Thu Jul 4 06:47:36 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 4 Jul 2019 16:47:36 +1000 Subject: jmx-dev RFR: 8170299: Debugger does not stop inside the low memory notifications code In-Reply-To: <75B5F778-DC49-494B-AC12-270F301677CA@oracle.com> References: <75B5F778-DC49-494B-AC12-270F301677CA@oracle.com> Message-ID: <60639d41-735a-00d3-c9db-1955f581b89a@oracle.com> Hi Daniil, On 4/07/2019 1:04 pm, Daniil Titov wrote: > Please review the change the fixes the problem with the debugger not stopping in the low memory notification code. > > The problem here is that the ServiceThread that calls these MXBean listeners is hidden from the external view that prevents the debugger from stopping in it. > > The fix introduces new NotificationThread that is visible to the external view and offloads the ServiceThread from sending low memory and other notifications that could result in Java calls ( GC and diagnostic commands notifications) by moving these activities in this new NotificationThread. There is a long and unfortunate history with this bug. The original incarnation of this fix was introducing a new thread at the Java library level, and I had some concerns about that: http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-December/022612.html That effort was resurrected at: http://mail.openjdk.java.net/pipermail/serviceability-dev/2018-July/024466.html and http://mail.openjdk.java.net/pipermail/serviceability-dev/2018-August/024849.html but was left somewhat in limbo. There was a lot of doubt about the right way to fix this bug and whether introducing a new thread was too disruptive. But introducing a new thread in the VM also has the same set of concerns! This needs consideration by the runtime team before going ahead. Introducing a new thread likes this needs to be examined in detail - particularly the synchronization interactions with other threads. It also introduces another monitor designated safepoint-never at a time when we are in the process of cleaning up monitors so that JavaThreads will only use safepoint-check-always monitors. Unfortunately I'm about to head out for two weeks vacation, and a number of other key runtime folk are also on vacation. but I'd ask that you hold off on this until we can look at it in more detail. Thanks, David ----- > Testing: Mach5 tier1,tier2 and tier3 tests succeeded. > > Webrev: https://cr.openjdk.java.net/~dtitov/8170299/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8170299 > > Thanks! > --Daniil > > From david.holmes at oracle.com Fri Jul 5 01:54:49 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 5 Jul 2019 11:54:49 +1000 Subject: jmx-dev RFR: 8185005: Improve performance of ThreadMXBean.getThreadInfo(long ids[], int maxDepth) In-Reply-To: References: <4C4212D0-BFFF-4C85-ACC6-05200F220C3F@oracle.com> Message-ID: <63cb79fb-99d1-79e8-0f28-b67dfacd858f@oracle.com> Hi Daniil, Sorry I found it harder to get to this this week than I would have hoped, so I've asked a couple of other runtime folk to please take a look while I'm on vacation. I do have some comments though. First, you've based this off the ResolvedMethodTable code and it isn't clear to me that everything in that code necessarily maps to this code. For example: 68 static uintx get_hash(Value const& value, bool* is_dead) { 69 *is_dead = false; ... 167 bool equals(ThreadTableEntry **value, bool* is_dead) { 168 *is_dead = false; "is_dead" is not relevant for this code and should be deleted. Then I'm not at all clear about getting the serviceThread to resize/rehash the table. Is there a specific reason to do that or did you just copy what is done for the ResolvedMethodTable? The usage constraints of that table may be different to this one and require using the serviceThread where here we may not need to. The initialization in universe_init() may not be right for the ThreadsTable, which is logically encapsulated by ThreadsSMRSupport. Overall there is complexity in ResolvedMethodTable code that I don't grok and it isn't obvious to me that it is all needed here. Further, the ConcurrentHashTable was only added in Java 11 so this will still need an alternate implementation - as per the bug report - to backport to Java 8. The is_valid_java_thread you added to ThreadsList isn't really needed. I know you've copied the core of that logic from the linear search code, but it really doesn't apply when using the table given the way you keep the table up to date. If you find the JavaThread using a given tid then that is the JavaThread. There's a typo PMIMORDIAL_JAVA_TID. I'm unclear about the tid==1 handling, you say "ThreadsSMRSupport::add_thread() is not called for the primordial thread" but the main thread does have this called via Threads:add just like every other created or attached thread. And note this isn't generally the "primordial thread" (which is the initial thread of a process) but just the "main" thread used to load the JVM. Overall I'm concerned about the duplication/overlap that now exists between the ThreadsList and the ThreadsTable. Maybe it is unavoidable to get the hashed lookup, or perhaps there is some way to get the desired functionality without the overlap? I'm hoping Dan will be able to chime in on that (ideally Robbin too but he is away this month.). And of course we still need to check overall footprint and performance impact. (E.g. if we have large numbers of threads might the rehash cause observable pauses in the other cleanup activities that the service thread does?). Thanks, David ----- On 29/06/2019 2:39 pm, David Holmes wrote: > Hi Daniil, > > The definition and use of this hashtable (yet another hashtable > implementation!) will need careful examination. We have to be concerned > about the cost of maintaining it when it may never even be queried. You > would need to look at footprint cost and performance impact. > > Unfortunately I'm just about to board a plane and will be out for the > next few days. I will try to look at this asap next week, but we will > need a lot more data on it. > > Thanks, > David > > On 28/06/2019 6:31 pm, Daniil Titov wrote: >> Please review the change that improves performance of ThreadMXBean >> MXBean methods returning the >> information for specific threads. The change introduces the thread >> table that uses ConcurrentHashTable >> to store one-to-one the mapping between the thread ids and JavaThread >> objects and replaces the linear >> search over the thread list in >> ThreadsList::find_JavaThread_from_java_tid(jlong tid) method with the >> lookup >> in the thread table. >> >> Testing: Mach5 tier1,tier2 and tier3 tests successfully passed. >> >> Webrev: https://cr.openjdk.java.net/~dtitov/8185005/webrev.01/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8185005 >> >> Thanks! >> >> Best regards, >> Daniil >> >> >> From daniil.x.titov at oracle.com Mon Jul 8 18:42:31 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Mon, 08 Jul 2019 11:42:31 -0700 Subject: jmx-dev RFR: 8170299: Debugger does not stop inside the low memory notifications code Message-ID: <92E6C72E-E1DC-48CB-9965-628AE5C3F9AB@oracle.com> Hi Serguei, Please review the new version of the fix that corrects the order of include statements in src/hotspot/share/runtime/notificationThread.cpp. The list of Include statements doesn't contain "#include "runtime/mutexLocker.hpp" since this include file is already included by runtime/interfaceSupport.inline.hpp that is in this list. I don't think we need the following function: static bool is_notification_thread(Thread* thread); For the ServiceThread the function is_service_thread(Thread* thread) is used only once in the code. It is used inside JVmtiDeferredEvent::post() to assert that the proper thread is used to post these events. Low memory, GC and diagnostic command notification never had such asserts so I'm not sure we need to introduce them regarding 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.spitsyn at oracle.com" wrote: Hi Daniil, I've not finished my review but it looks good in general. A couple of quick comments. https://cr.openjdk.java.net/~dtitov/8170299/webrev.01/src/hotspot/share/runtime/notificationThread.hpp.html I wonder if this function is also needed: static bool is_notification_thread(Thread* thread); https://cr.openjdk.java.net/~dtitov/8170299/webrev.01/src/hotspot/share/runtime/notificationThread.cpp.html I wonder why this include statement is missed: #include "runtime/mutexLocker.hpp" Also, these have to be correctly ordred: 29 #include "runtime/notificationThread.hpp" 30 #include "services/lowMemoryDetector.hpp" 31 #include "services/gcNotifier.hpp" 32 #include "services/diagnosticArgument.hpp" 33 #include "services/diagnosticFramework.hpp" Thanks, Serguei On 7/3/19 8:04 PM, Daniil Titov wrote: > Please review the change the fixes the problem with the debugger not stopping in the low memory notification code. > > The problem here is that the ServiceThread that calls these MXBean listeners is hidden from the external view that prevents the debugger from stopping in it. > > The fix introduces new NotificationThread that is visible to the external view and offloads the ServiceThread from sending low memory and other notifications that could result in Java calls ( GC and diagnostic commands notifications) by moving these activities in this new NotificationThread. > > Testing: Mach5 tier1,tier2 and tier3 tests succeeded. > > Webrev: https://cr.openjdk.java.net/~dtitov/8170299/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8170299 > > Thanks! > --Daniil > > From serguei.spitsyn at oracle.com Mon Jul 8 22:09:39 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 8 Jul 2019 15:09:39 -0700 Subject: jmx-dev RFR: 8170299: Debugger does not stop inside the low memory notifications code In-Reply-To: <92E6C72E-E1DC-48CB-9965-628AE5C3F9AB@oracle.com> References: <92E6C72E-E1DC-48CB-9965-628AE5C3F9AB@oracle.com> Message-ID: <9e1ac22e-e425-1623-2e49-91418711d1c7@oracle.com> An HTML attachment was scrubbed... URL: From daniel.daugherty at oracle.com Mon Jul 8 22:24:18 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 8 Jul 2019 18:24:18 -0400 Subject: jmx-dev RFR: 8185005: Improve performance of ThreadMXBean.getThreadInfo(long ids[], int maxDepth) In-Reply-To: <6E7B043A-4647-4931-977C-1854CA7EBEC1@oracle.com> References: <4C4212D0-BFFF-4C85-ACC6-05200F220C3F@oracle.com> <2d6dede1-aa79-99ce-a823-773fa2e19827@oracle.com> <6E7B043A-4647-4931-977C-1854CA7EBEC1@oracle.com> Message-ID: On 6/29/19 12:06 PM, Daniil Titov wrote: > Hi Serguei and David, > > Serguei is right, ThreadTable::find_thread(java_tid) cannot return a JavaThread with an unmatched java_tid. > > Please find a new version of the fix that includes the changes Serguei suggested. > > Regarding the concern about the maintaining the thread table when it may never even be queried, one of > the options could be to add ThreadTable ::isEnabled flag, set it to "false" by default, and wrap the calls to the thread table > in ThreadsSMRSupport add_thread() and remove_thread() methods to check this flag. > > When ThreadsList::find_JavaThread_from_java_tid() is called for the first time it could check if ThreadTable ::isEnabled > Is on and if not then set it on and populate the thread table with all existing threads from the thread list. I have the same concerns as David H. about this new ThreadTable. ThreadsList::find_JavaThread_from_java_tid() is only called from code in src/hotspot/share/services/management.cpp so I think that table needs to enabled and populated only if it is going to be used. I've taken a look at the webrev below and I see that David has followed up with additional comments. Before I do a crawl through code review for this, I would like to see the ThreadTable stuff made optional and David's other comments addressed. Another possible optimization is for callers of find_JavaThread_from_java_tid() to save the calling thread's tid value before they loop and if the current tid == saved_tid then use the current JavaThread* instead of calling find_JavaThread_from_java_tid() to get the JavaThread*. Dan > > Webrev: https://cr.openjdk.java.net/~dtitov/8185005/webrev.02/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8185005 > > Thanks! > --Daniil > > From: > Organization: Oracle Corporation > Date: Friday, June 28, 2019 at 7:56 PM > To: Daniil Titov , OpenJDK Serviceability , "hotspot-runtime-dev at openjdk.java.net" , "jmx-dev at openjdk.java.net" > Subject: Re: RFR: 8185005: Improve performance of ThreadMXBean.getThreadInfo(long ids[], int maxDepth) > > Hi Daniil, > > I have several quick comments. > > The indent in the hotspot c/c++ files has to be 2, not 4. > > https://cr.openjdk.java.net/~dtitov/8185005/webrev.01/src/hotspot/share/runtime/threadSMR.cpp.frames.html > 614 JavaThread* ThreadsList::find_JavaThread_from_java_tid(jlong java_tid) const { > 615 JavaThread* java_thread = ThreadTable::find_thread(java_tid); > 616 if (java_thread == NULL && java_tid == PMIMORDIAL_JAVA_TID) { > 617 // ThreadsSMRSupport::add_thread() is not called for the primordial > 618 // thread. Thus, we find this thread with a linear search and add it > 619 // to the thread table. > 620 for (uint i = 0; i < length(); i++) { > 621 JavaThread* thread = thread_at(i); > 622 if (is_valid_java_thread(java_tid,thread)) { > 623 ThreadTable::add_thread(java_tid, thread); > 624 return thread; > 625 } > 626 } > 627 } else if (java_thread != NULL && is_valid_java_thread(java_tid, java_thread)) { > 628 return java_thread; > 629 } > 630 return NULL; > 631 } > 632 bool ThreadsList::is_valid_java_thread(jlong java_tid, JavaThread* java_thread) { > 633 oop tobj = java_thread->threadObj(); > 634 // Ignore the thread if it hasn't run yet, has exited > 635 // or is starting to exit. > 636 return (tobj != NULL && !java_thread->is_exiting() && > 637 java_tid == java_lang_Thread::thread_id(tobj)); > 638 } > > 615 JavaThread* java_thread = ThreadTable::find_thread(java_tid); > > I'd suggest to rename find_thread() to find_thread_by_tid(). > > A space is missed after the comma: > ? 622 if (is_valid_java_thread(java_tid,thread)) { > > An empty line is needed before L632. > > The name 'is_valid_java_thread' looks wrong (or confusing) to me. > Something like 'is_alive_java_thread_with_tid()' would be better. > It'd better to list parameters in the opposite order. > > The call to is_valid_java_thread() is confusing: > ?? 627 } else if (java_thread != NULL && is_valid_java_thread(java_tid, java_thread)) { > > Why would the call ThreadTable::find_thread(java_tid) return a JavaThread with an unmatched java_tid? > > > Thanks, > Serguei > > On 6/28/19, 9:40 PM, "David Holmes" wrote: > > Hi Daniil, > > The definition and use of this hashtable (yet another hashtable > implementation!) will need careful examination. We have to be concerned > about the cost of maintaining it when it may never even be queried. You > would need to look at footprint cost and performance impact. > > Unfortunately I'm just about to board a plane and will be out for the > next few days. I will try to look at this asap next week, but we will > need a lot more data on it. > > Thanks, > David > > On 6/28/19 3:31 PM, Daniil Titov wrote: > Please review the change that improves performance of ThreadMXBean MXBean methods returning the > information for specific threads. The change introduces the thread table that uses ConcurrentHashTable > to store one-to-one the mapping between the thread ids and JavaThread objects and replaces the linear > search over the thread list in ThreadsList::find_JavaThread_from_java_tid(jlong tid) method with the lookup > in the thread table. > > Testing: Mach5 tier1,tier2 and tier3 tests successfully passed. > > Webrev: https://cr.openjdk.java.net/~dtitov/8185005/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8185005 > > Thanks! > > Best regards, > Daniil > > > > > > > From daniil.x.titov at oracle.com Mon Jul 8 23:11:44 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Mon, 08 Jul 2019 16:11:44 -0700 Subject: jmx-dev RFR: 8170299: Debugger does not stop inside the low memory notifications code In-Reply-To: <60639d41-735a-00d3-c9db-1955f581b89a@oracle.com> References: <75B5F778-DC49-494B-AC12-270F301677CA@oracle.com> <60639d41-735a-00d3-c9db-1955f581b89a@oracle.com> Message-ID: <2BDA2105-D987-438C-BC2A-052496F07B7F@oracle.com> Hi David, Sure, I will put it on hold till you are back from the vacations. Webrev: https://cr.openjdk.java.net/~dtitov/8170299/webrev.02/ Bug: https://bugs.openjdk.java.net/browse/JDK-8170299 Have a nice vacations! Best regards, Daniil ? On 7/3/19, 11:47 PM, "David Holmes" wrote: Hi Daniil, On 4/07/2019 1:04 pm, Daniil Titov wrote: > Please review the change the fixes the problem with the debugger not stopping in the low memory notification code. > > The problem here is that the ServiceThread that calls these MXBean listeners is hidden from the external view that prevents the debugger from stopping in it. > > The fix introduces new NotificationThread that is visible to the external view and offloads the ServiceThread from sending low memory and other notifications that could result in Java calls ( GC and diagnostic commands notifications) by moving these activities in this new NotificationThread. There is a long and unfortunate history with this bug. The original incarnation of this fix was introducing a new thread at the Java library level, and I had some concerns about that: http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-December/022612.html That effort was resurrected at: http://mail.openjdk.java.net/pipermail/serviceability-dev/2018-July/024466.html and http://mail.openjdk.java.net/pipermail/serviceability-dev/2018-August/024849.html but was left somewhat in limbo. There was a lot of doubt about the right way to fix this bug and whether introducing a new thread was too disruptive. But introducing a new thread in the VM also has the same set of concerns! This needs consideration by the runtime team before going ahead. Introducing a new thread likes this needs to be examined in detail - particularly the synchronization interactions with other threads. It also introduces another monitor designated safepoint-never at a time when we are in the process of cleaning up monitors so that JavaThreads will only use safepoint-check-always monitors. Unfortunately I'm about to head out for two weeks vacation, and a number of other key runtime folk are also on vacation. but I'd ask that you hold off on this until we can look at it in more detail. Thanks, David ----- > Testing: Mach5 tier1,tier2 and tier3 tests succeeded. > > Webrev: https://cr.openjdk.java.net/~dtitov/8170299/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8170299 > > Thanks! > --Daniil > > From daniil.x.titov at oracle.com Mon Jul 8 23:24:15 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Mon, 08 Jul 2019 16:24:15 -0700 Subject: jmx-dev RFR: 8170299: Debugger does not stop inside the low memory notifications code In-Reply-To: <9e1ac22e-e425-1623-2e49-91418711d1c7@oracle.com> References: <92E6C72E-E1DC-48CB-9965-628AE5C3F9AB@oracle.com> <9e1ac22e-e425-1623-2e49-91418711d1c7@oracle.com> Message-ID: <5324D2D0-94CD-4A79-ADEB-064E713D34F7@oracle.com> Hi Serguei, I will put it on hold as David asked but before doing so I just wanted to give a quick reply to the questions you asked. Thanks! Best regards, Daniil From: "serguei.spitsyn at oracle.com" Date: Monday, July 8, 2019 at 3:09 PM To: Daniil Titov , OpenJDK Serviceability , "hotspot-runtime-dev at openjdk.java.net" , "jmx-dev at openjdk.java.net" , David Holmes Subject: Re: RFR: 8170299: Debugger does not stop inside the low memory notifications code Hi Daniil, Did you see a message from David Holmes? I do not see your reply. Specifically, David asked to hold on with this while he is on vacation for two weeks: > But introducing a new thread in the VM also has the same set of concerns! > This needs consideration by the runtime team before going ahead. > Introducing a new thread likes this needs to be examined in detail - > particularly the synchronization interactions with other threads. > > It also introduces another monitor designated safepoint-never at a time > when we are in the process of cleaning up monitors so that > JavaThreads will only use safepoint-check-always monitors. > > Unfortunately I'm about to head out for two weeks vacation, and > a number of other key runtime folk are also on vacation. > But I'd ask that you hold off on this until we can look at it in more detail. In fact, I was expecting this kind of concerns from David. Thanks, Serguei On 7/8/19 11:42, Daniil Titov wrote: Hi Serguei, Please review the new version of the fix that corrects the order of include statements in src/hotspot/share/runtime/notificationThread.cpp. The list of Include statements doesn't contain? "#include "runtime/mutexLocker.hpp" since this include file is already included by runtime/interfaceSupport.inline.hpp that is in this list. I don't think we need? the following function: static bool is_notification_thread(Thread* thread); ??? For the ServiceThread the function is_service_thread(Thread* thread) is used only once in the code. It is used inside JVmtiDeferredEvent::post() to assert that the proper thread is used to post these events. Low memory, GC and diagnostic command notification never had such asserts so I'm not sure? we need to introduce them regarding 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.spitsyn at oracle.com" wrote: ??? Hi Daniil, ??? ????I've not finished my review but it looks good in general. ??? ????A couple of quick comments. ??? ???? ????https://cr.openjdk.java.net/~dtitov/8170299/webrev.01/src/hotspot/share/runtime/notificationThread.hpp.html ??? ??????I wonder if this function is also needed: ??????? static bool is_notification_thread(Thread* thread); ??? ???? ????https://cr.openjdk.java.net/~dtitov/8170299/webrev.01/src/hotspot/share/runtime/notificationThread.cpp.html ??? ????I wonder why this include statement is missed: ?????? #include "runtime/mutexLocker.hpp" ??? ????Also, these have to be correctly ordred: ??? ???????29 #include "runtime/notificationThread.hpp" ?????? 30 #include "services/lowMemoryDetector.hpp" ?????? 31 #include "services/gcNotifier.hpp" ?????? 32 #include "services/diagnosticArgument.hpp" ?????? 33 #include "services/diagnosticFramework.hpp" ??? ???? ????Thanks, ? ??Serguei ??? ???? ????On 7/3/19 8:04 PM, Daniil Titov wrote: ??? > Please review the change the fixes the problem with the debugger not stopping in the low memory notification code. ??? > ??? > The problem here is that the ServiceThread that calls these MXBean listeners is hidden from the external view that prevents the debugger from stopping in it. ??? > ??? > The fix introduces new NotificationThread that is visible to the external view and offloads the ServiceThread from sending low memory and other notifications that could result in Java calls ( GC and diagnostic commands notifications) by moving these activities in this new NotificationThread. ??? > ??? > Testing: Mach5 tier1,tier2 and tier3 tests succeeded. ??? > ??? > Webrev: https://cr.openjdk.java.net/~dtitov/8170299/webrev.01/ ??? > Bug: https://bugs.openjdk.java.net/browse/JDK-8170299 ??? > ??? > Thanks! ??? > --Daniil ??? > ??? > ??? ???? -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Tue Jul 9 08:37:18 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 9 Jul 2019 01:37:18 -0700 Subject: jmx-dev RFR: 8170299: Debugger does not stop inside the low memory notifications code In-Reply-To: <5324D2D0-94CD-4A79-ADEB-064E713D34F7@oracle.com> References: <92E6C72E-E1DC-48CB-9965-628AE5C3F9AB@oracle.com> <9e1ac22e-e425-1623-2e49-91418711d1c7@oracle.com> <5324D2D0-94CD-4A79-ADEB-064E713D34F7@oracle.com> Message-ID: <0221970f-ec8c-6ffc-836e-2adf6eb09eb0@oracle.com> An HTML attachment was scrubbed... URL: From daniil.x.titov at oracle.com Tue Jul 9 15:37:42 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Tue, 09 Jul 2019 08:37:42 -0700 Subject: jmx-dev 8170299: Debugger does not stop inside the low memory notifications code In-Reply-To: <0221970f-ec8c-6ffc-836e-2adf6eb09eb0@oracle.com> References: <92E6C72E-E1DC-48CB-9965-628AE5C3F9AB@oracle.com> <9e1ac22e-e425-1623-2e49-91418711d1c7@oracle.com> <5324D2D0-94CD-4A79-ADEB-064E713D34F7@oracle.com> <0221970f-ec8c-6ffc-836e-2adf6eb09eb0@oracle.com> Message-ID: <1BABD981-5D4A-4018-B899-16EBD0D33C6E@oracle.com> Hi Serguei, I tried to answer your question regarding "runtime/mutexLocker.hpp" in my reply. > The list of Include statements doesn't contain "#include "runtime/mutexLocker.hpp" since this include file is already included by runtime/interfaceSupport.inline.hpp that is in this list. File "src/hotspot/share/runtime/notificationThread.cpp" includes "runtime/interfaceSupport.inline.hpp" and the header file "runtime/interfaceSupport.inline.hpp", 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 included. Thanks, Daniil From: "serguei.spitsyn at oracle.com" Date: Tuesday, July 9, 2019 at 1:37 AM To: Daniil Titov , OpenJDK Serviceability , "hotspot-runtime-dev at openjdk.java.net" , "jmx-dev at openjdk.java.net" , David Holmes Subject: Re: RFR: 8170299: Debugger does not stop inside the low memory notifications code Hi Daniil, On 7/8/19 16:24, Daniil Titov wrote: Hi Serguei, ? I will put it on hold as David asked but before doing so I just wanted to give a quick reply to the questions you asked. You did not answer my question about include: ?????? #include "runtime/mutexLocker.hpp" I'll provide a complete review after you sort out the David's concerns. Thanks, Serguei ? Thanks! ? Best regards, Daniil ? ? ? From: mailto:serguei.spitsyn at oracle.com mailto:serguei.spitsyn at oracle.com Date: Monday, July 8, 2019 at 3:09 PM To: Daniil Titov mailto:daniil.x.titov at oracle.com, OpenJDK Serviceability mailto:serviceability-dev at openjdk.java.net, mailto:hotspot-runtime-dev at openjdk.java.net mailto:hotspot-runtime-dev at openjdk.java.net, mailto:jmx-dev at openjdk.java.net mailto:jmx-dev at openjdk.java.net, David Holmes mailto:david.holmes at oracle.com Subject: Re: RFR: 8170299: Debugger does not stop inside the low memory notifications code ? Hi Daniil, Did you see a message from David Holmes? I do not see your reply. Specifically, David asked to hold on with this while he is on vacation for two weeks: > But introducing a new thread in the VM also has the same set of concerns! > This needs consideration by the runtime team before going ahead. > Introducing a new thread likes this needs to be examined in detail - > particularly the synchronization interactions with other threads. > > It also introduces another monitor designated safepoint-never at a time > when we are in the process of cleaning up monitors so that > JavaThreads will only use safepoint-check-always monitors. > > Unfortunately I'm about to head out for two weeks vacation, and > a number of other key runtime folk are also on vacation. > But I'd ask that you hold off on this until we can look at it in more detail. In fact, I was expecting this kind of concerns from David. Thanks, Serguei On 7/8/19 11:42, Daniil Titov wrote: Hi Serguei, ? Please review the new version of the fix that corrects the order of include statements in src/hotspot/share/runtime/notificationThread.cpp. ? The list of Include statements doesn't contain? "#include "runtime/mutexLocker.hpp" since this include file is already included by runtime/interfaceSupport.inline.hpp that is in this list. ? I don't think we need? the following function: static bool is_notification_thread(Thread* thread); ??? For the ServiceThread the function is_service_thread(Thread* thread) is used only once in the code. It is used inside JVmtiDeferredEvent::post() to assert that the proper thread is used to post these events. Low memory, GC and diagnostic command notification never had such asserts so I'm not sure? we need to introduce them regarding 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, mailto:serguei.spitsyn at oracle.com mailto:serguei.spitsyn at oracle.com wrote: ? ??? Hi Daniil, ??? ????I've not finished my review but it looks good in general. ??? ????A couple of quick comments. ??? ???? ????https://cr.openjdk.java.net/~dtitov/8170299/webrev.01/src/hotspot/share/runtime/notificationThread.hpp.html ??? ??????I wonder if this function is also needed: ??????? static bool is_notification_thread(Thread* thread); ??? ???? ????https://cr.openjdk.java.net/~dtitov/8170299/webrev.01/src/hotspot/share/runtime/notificationThread.cpp.html ??? ????I wonder why this include statement is missed: ?????? #include "runtime/mutexLocker.hpp" ??? ????Also, these have to be correctly ordred: ??? ???????29 #include "runtime/notificationThread.hpp" ?????? 30 #include "services/lowMemoryDetector.hpp" ?????? 31 #include "services/gcNotifier.hpp" ?????? 32 #include "services/diagnosticArgument.hpp" ?????? 33 #include "services/diagnosticFramework.hpp" ??? ???? ????Thanks, ? ??Serguei ??? ???? ????On 7/3/19 8:04 PM, Daniil Titov wrote: ??? > Please review the change the fixes the problem with the debugger not stopping in the low memory notification code. ??? > ??? > The problem here is that the ServiceThread that calls these MXBean listeners is hidden from the external view that prevents the debugger from stopping in it. ??? > ??? > The fix introduces new NotificationThread that is visible to the external view and offloads the ServiceThread from sending low memory and other notifications that could result in Java calls ( GC and diagnostic commands notifications) by moving these activities in this new NotificationThread. ??? > ??? > Testing: Mach5 tier1,tier2 and tier3 tests succeeded. ??? > ??? > Webrev: https://cr.openjdk.java.net/~dtitov/8170299/webrev.01/ ??? > Bug: https://bugs.openjdk.java.net/browse/JDK-8170299 ??? > ??? > Thanks! ??? > --Daniil ??? > ??? > ??? ???? ? ? From serguei.spitsyn at oracle.com Tue Jul 9 16:02:11 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 9 Jul 2019 09:02:11 -0700 Subject: jmx-dev 8170299: Debugger does not stop inside the low memory notifications code In-Reply-To: <1BABD981-5D4A-4018-B899-16EBD0D33C6E@oracle.com> References: <92E6C72E-E1DC-48CB-9965-628AE5C3F9AB@oracle.com> <9e1ac22e-e425-1623-2e49-91418711d1c7@oracle.com> <5324D2D0-94CD-4A79-ADEB-064E713D34F7@oracle.com> <0221970f-ec8c-6ffc-836e-2adf6eb09eb0@oracle.com> <1BABD981-5D4A-4018-B899-16EBD0D33C6E@oracle.com> Message-ID: Hi Daniil, Missed it, sorry. Thanks, Serguei On 7/9/19 08:37, Daniil Titov wrote: > Hi Serguei, > > I tried to answer your question regarding "runtime/mutexLocker.hpp" in my reply. > >> The list of Include statements doesn't contain "#include "runtime/mutexLocker.hpp" since this include file is already included by runtime/interfaceSupport.inline.hpp that is in this list. > File "src/hotspot/share/runtime/notificationThread.cpp" includes "runtime/interfaceSupport.inline.hpp" and the header file "runtime/interfaceSupport.inline.hpp", 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 included. > > Thanks, > Daniil > > From: "serguei.spitsyn at oracle.com" > Date: Tuesday, July 9, 2019 at 1:37 AM > To: Daniil Titov , OpenJDK Serviceability , "hotspot-runtime-dev at openjdk.java.net" , "jmx-dev at openjdk.java.net" , David Holmes > Subject: Re: RFR: 8170299: Debugger does not stop inside the low memory notifications code > > Hi Daniil, > > > On 7/8/19 16:24, Daniil Titov wrote: > Hi Serguei, > > I will put it on hold as David asked but before doing so I just wanted to give a quick reply to the questions you asked. > > You did not answer my question about include: > ?????? #include "runtime/mutexLocker.hpp" > > I'll provide a complete review after you sort out the David's concerns. > > Thanks, > Serguei > > Thanks! > > Best regards, > Daniil > > > > From: mailto:serguei.spitsyn at oracle.com mailto:serguei.spitsyn at oracle.com > Date: Monday, July 8, 2019 at 3:09 PM > To: Daniil Titov mailto:daniil.x.titov at oracle.com, OpenJDK Serviceability mailto:serviceability-dev at openjdk.java.net, mailto:hotspot-runtime-dev at openjdk.java.net mailto:hotspot-runtime-dev at openjdk.java.net, mailto:jmx-dev at openjdk.java.net mailto:jmx-dev at openjdk.java.net, David Holmes mailto:david.holmes at oracle.com > Subject: Re: RFR: 8170299: Debugger does not stop inside the low memory notifications code > > Hi Daniil, > > Did you see a message from David Holmes? > I do not see your reply. > > Specifically, David asked to hold on with this while he is on vacation for two weeks: > >> But introducing a new thread in the VM also has the same set of concerns! >> This needs consideration by the runtime team before going ahead. >> Introducing a new thread likes this needs to be examined in detail - >> particularly the synchronization interactions with other threads. >> >> It also introduces another monitor designated safepoint-never at a time >> when we are in the process of cleaning up monitors so that >> JavaThreads will only use safepoint-check-always monitors. >> >> Unfortunately I'm about to head out for two weeks vacation, and >> a number of other key runtime folk are also on vacation. >> But I'd ask that you hold off on this until we can look at it in more detail. > > In fact, I was expecting this kind of concerns from David. > > Thanks, > Serguei > > > On 7/8/19 11:42, Daniil Titov wrote: > Hi Serguei, > > Please review the new version of the fix that corrects the order of include statements in src/hotspot/share/runtime/notificationThread.cpp. > > The list of Include statements doesn't contain? "#include "runtime/mutexLocker.hpp" since this include file is already included by runtime/interfaceSupport.inline.hpp that is in this list. > > I don't think we need? the following function: > static bool is_notification_thread(Thread* thread); > > For the ServiceThread the function is_service_thread(Thread* thread) is used only once in the code. It is used inside JVmtiDeferredEvent::post() to assert that the proper thread is used to post these events. Low memory, GC and diagnostic command notification never had such asserts so I'm not sure? we need to introduce them regarding 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, mailto:serguei.spitsyn at oracle.com mailto:serguei.spitsyn at oracle.com wrote: > > ??? Hi Daniil, > > ????I've not finished my review but it looks good in general. > > ????A couple of quick comments. > > > ????https://cr.openjdk.java.net/~dtitov/8170299/webrev.01/src/hotspot/share/runtime/notificationThread.hpp.html > > ??????I wonder if this function is also needed: > ??????? static bool is_notification_thread(Thread* thread); > > > ????https://cr.openjdk.java.net/~dtitov/8170299/webrev.01/src/hotspot/share/runtime/notificationThread.cpp.html > > ????I wonder why this include statement is missed: > ?????? #include "runtime/mutexLocker.hpp" > > ????Also, these have to be correctly ordred: > > ???????29 #include "runtime/notificationThread.hpp" > ?????? 30 #include "services/lowMemoryDetector.hpp" > ?????? 31 #include "services/gcNotifier.hpp" > ?????? 32 #include "services/diagnosticArgument.hpp" > ?????? 33 #include "services/diagnosticFramework.hpp" > > > ????Thanks, > ? ??Serguei > > > ????On 7/3/19 8:04 PM, Daniil Titov wrote: > ??? > Please review the change the fixes the problem with the debugger not stopping in the low memory notification code. > ??? > > ??? > The problem here is that the ServiceThread that calls these MXBean listeners is hidden from the external view that prevents the debugger from stopping in it. > ??? > > ??? > The fix introduces new NotificationThread that is visible to the external view and offloads the ServiceThread from sending low memory and other notifications that could result in Java calls ( GC and diagnostic commands notifications) by moving these activities in this new NotificationThread. > ??? > > ??? > Testing: Mach5 tier1,tier2 and tier3 tests succeeded. > ??? > > ??? > Webrev: https://cr.openjdk.java.net/~dtitov/8170299/webrev.01/ > ??? > Bug: https://bugs.openjdk.java.net/browse/JDK-8170299 > ??? > > ??? > Thanks! > ??? > --Daniil > ??? > > ??? > > > > > > > > > > From daniil.x.titov at oracle.com Thu Jul 11 17:16:32 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Thu, 11 Jul 2019 10:16:32 -0700 Subject: jmx-dev RFR: 8221303: sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java fails due to java.rmi.server.ExportException: Port already in use Message-ID: <19FCBDF1-70D7-4CC3-BFBE-945857301282@oracle.com> Please review the change that fixes an intermittent failure of sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java test due to ports collision. The tests finds all network interfaces and for every interface starts a separate process that tests the connection to JMX agent server for a specific ports/interface combination. The test was changed to retry in case of the failure. If the subprocess fails to bind and the number of retry attempts doesn't exceed the limit a new pair of random ports is selected and the test is run again. Webrev: http://cr.openjdk.java.net/~dtitov/8221303/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8221303 Thanks! --Daniil From daniil.x.titov at oracle.com Tue Jul 16 23:12:23 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Tue, 16 Jul 2019 16:12:23 -0700 Subject: jmx-dev RFR: 8206179: com/sun/management/OperatingSystemMXBean/GetCommittedVirtualMemorySize.java fails with Committed virtual memory size illegal value Message-ID: <96528910-EBC3-4D31-96A0-E5908D736083@oracle.com> Please review the change that fixes the failure of the test. The test assumes that the amount of the virtual memory committed to the process could not be greater than the total of the RAM and the swap size the machine has, however, it is not correct if, for example, the process uses a memory-mapped file. That results in the test failure on the machines where the total of the RAM and the size of the swap file is less than the memory committed to the test process. Webrev: https://cr.openjdk.java.net/~dtitov/8206179/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8206179 Thanks, --Daniil From serguei.spitsyn at oracle.com Tue Jul 16 23:20:48 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 16 Jul 2019 16:20:48 -0700 Subject: jmx-dev RFR: 8206179: com/sun/management/OperatingSystemMXBean/GetCommittedVirtualMemorySize.java fails with Committed virtual memory size illegal value In-Reply-To: <96528910-EBC3-4D31-96A0-E5908D736083@oracle.com> References: <96528910-EBC3-4D31-96A0-E5908D736083@oracle.com> Message-ID: <2cbe14ee-42d9-9371-161b-ca01368206e2@oracle.com> Hi Daniil, It looks good to me. Thanks, Serguei On 7/16/19 4:12 PM, Daniil Titov wrote: > Please review the change that fixes the failure of the test. > > The test assumes that the amount of the virtual memory committed to the process could not > be greater than the total of the RAM and the swap size the machine has, however, it is not > correct if, for example, the process uses a memory-mapped file. > > That results in the test failure on the machines where the total of the RAM and the size of the swap > file is less than the memory committed to the test process. > > Webrev: https://cr.openjdk.java.net/~dtitov/8206179/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8206179 > > Thanks, > --Daniil > > From chris.plummer at oracle.com Tue Jul 16 23:58:26 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 16 Jul 2019 16:58:26 -0700 Subject: jmx-dev RFR: 8206179: com/sun/management/OperatingSystemMXBean/GetCommittedVirtualMemorySize.java fails with Committed virtual memory size illegal value In-Reply-To: <96528910-EBC3-4D31-96A0-E5908D736083@oracle.com> References: <96528910-EBC3-4D31-96A0-E5908D736083@oracle.com> Message-ID: <1fb6543a-4957-f738-73fb-bc94e222a110@oracle.com> Looks good. Chris On 7/16/19 4:12 PM, Daniil Titov wrote: > Please review the change that fixes the failure of the test. > > The test assumes that the amount of the virtual memory committed to the process could not > be greater than the total of the RAM and the swap size the machine has, however, it is not > correct if, for example, the process uses a memory-mapped file. > > That results in the test failure on the machines where the total of the RAM and the size of the swap > file is less than the memory committed to the test process. > > Webrev: https://cr.openjdk.java.net/~dtitov/8206179/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8206179 > > Thanks, > --Daniil > > From daniil.x.titov at oracle.com Wed Jul 17 17:22:38 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Wed, 17 Jul 2019 10:22:38 -0700 Subject: jmx-dev 8206179: com/sun/management/OperatingSystemMXBean/GetCommittedVirtualMemorySize.java fails with Committed virtual memory size illegal value In-Reply-To: <1fb6543a-4957-f738-73fb-bc94e222a110@oracle.com> References: <96528910-EBC3-4D31-96A0-E5908D736083@oracle.com> <1fb6543a-4957-f738-73fb-bc94e222a110@oracle.com> Message-ID: <0A708C40-E673-4EFE-B851-7D7C1C806670@oracle.com> Thank you, Chris and Serguei, for reviewing this change! Best regards, Daniil ?On 7/16/19, 4:58 PM, "Chris Plummer" wrote: Looks good. Chris On 7/16/19 4:12 PM, Daniil Titov wrote: > Please review the change that fixes the failure of the test. > > The test assumes that the amount of the virtual memory committed to the process could not > be greater than the total of the RAM and the swap size the machine has, however, it is not > correct if, for example, the process uses a memory-mapped file. > > That results in the test failure on the machines where the total of the RAM and the size of the swap > file is less than the memory committed to the test process. > > Webrev: https://cr.openjdk.java.net/~dtitov/8206179/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8206179 > > Thanks, > --Daniil > > From chris.plummer at oracle.com Wed Jul 17 19:11:56 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 17 Jul 2019 12:11:56 -0700 Subject: jmx-dev RFR: 8221303: sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java fails due to java.rmi.server.ExportException: Port already in use In-Reply-To: <19FCBDF1-70D7-4CC3-BFBE-945857301282@oracle.com> References: <19FCBDF1-70D7-4CC3-BFBE-945857301282@oracle.com> Message-ID: <070f6ca7-c235-89da-9ea1-0702027a6e34@oracle.com> Hi Daniil, It's a little unclear to me why you moved from ProcessThread to TestProcessThread + Process. An explanation of that would make it easier to understand many of the changes. thanks, Chris On 7/11/19 10:16 AM, Daniil Titov wrote: > Please review the change that fixes an intermittent failure of sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java > test due to ports collision. The tests finds all network interfaces and for every interface starts a separate process that tests > the connection to JMX agent server for a specific ports/interface combination. > > The test was changed to retry in case of the failure. If the subprocess fails to bind and the number > of retry attempts doesn't exceed the limit a new pair of random ports is selected and the test is run again. > > Webrev: http://cr.openjdk.java.net/~dtitov/8221303/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8221303 > > Thanks! > --Daniil > > From daniil.x.titov at oracle.com Wed Jul 17 19:46:05 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Wed, 17 Jul 2019 12:46:05 -0700 Subject: jmx-dev 8221303: sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java fails due to java.rmi.server.ExportException: Port already in use In-Reply-To: <070f6ca7-c235-89da-9ea1-0702027a6e34@oracle.com> References: <19FCBDF1-70D7-4CC3-BFBE-945857301282@oracle.com> <070f6ca7-c235-89da-9ea1-0702027a6e34@oracle.com> Message-ID: Hi Chris, > It's a little unclear to me why you moved from ProcessThread to > TestProcessThread + Process. An explanation of that would make it easier > to understand many of the changes. There are two reasons for that: 1) For every network interface the test starts a separate thread that runs the test for this interface. We want that if the test fails due to the bind error the thread not to exit but try to repeat the test several times. jdk.test.lib.thread.ProcessThread doesn't allow this. 2) To filter out the cases when the test fails due to the bind error we need to parse the process output. jdk.test.lib.thread.ProcessThread registers its own pumps for stdin and sdtout (by calling ProcessTools.startProcess()) that consume all output of the process and prevent the output analyzer from collecting this output. Thanks! --Daniil ?On 7/17/19, 12:11 PM, "Chris Plummer" wrote: Hi Daniil, It's a little unclear to me why you moved from ProcessThread to TestProcessThread + Process. An explanation of that would make it easier to understand many of the changes. thanks, Chris On 7/11/19 10:16 AM, Daniil Titov wrote: > Please review the change that fixes an intermittent failure of sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java > test due to ports collision. The tests finds all network interfaces and for every interface starts a separate process that tests > the connection to JMX agent server for a specific ports/interface combination. > > The test was changed to retry in case of the failure. If the subprocess fails to bind and the number > of retry attempts doesn't exceed the limit a new pair of random ports is selected and the test is run again. > > Webrev: http://cr.openjdk.java.net/~dtitov/8221303/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8221303 > > Thanks! > --Daniil > > From alexey.menkov at oracle.com Wed Jul 17 20:30:31 2019 From: alexey.menkov at oracle.com (Alex Menkov) Date: Wed, 17 Jul 2019 13:30:31 -0700 Subject: jmx-dev 8221303: sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java fails due to java.rmi.server.ExportException: Port already in use In-Reply-To: References: <19FCBDF1-70D7-4CC3-BFBE-945857301282@oracle.com> <070f6ca7-c235-89da-9ea1-0702027a6e34@oracle.com> Message-ID: <0c59c27e-c8b0-2c8d-8b3b-7bf7dc987c71@oracle.com> Hi Daniil, The fix looks good in general. Couple cosmetic notes (no new webrev required): 162 needRetry = runTest(); 163 } 164 while (needRetry && (attempts++ < MAX_RETRY_ATTEMTS)); Please move "while" to the prev line: 163 } while (needRetry && (attempts++ < MAX_RETRY_ATTEMTS)); 242 System.out.println("Test FAILURE on" + name + " reason: The expected line \"" + READY_MSG 243 + "\" is not present in the process output"); Please add space: "Test FAILURE on " + name --alex On 07/17/2019 12:46, Daniil Titov wrote: > Hi Chris, > >> It's a little unclear to me why you moved from ProcessThread to >> TestProcessThread + Process. An explanation of that would make it easier >> to understand many of the changes. > > There are two reasons for that: > 1) For every network interface the test starts a separate thread that runs the test for this interface. We want that if the test fails > due to the bind error the thread not to exit but try to repeat the test several times. jdk.test.lib.thread.ProcessThread doesn't allow this. > 2) To filter out the cases when the test fails due to the bind error we need to parse the process output. jdk.test.lib.thread.ProcessThread > registers its own pumps for stdin and sdtout (by calling ProcessTools.startProcess()) that consume all output of the process and prevent > the output analyzer from collecting this output. > > Thanks! > --Daniil > > ?On 7/17/19, 12:11 PM, "Chris Plummer" wrote: > > Hi Daniil, > > It's a little unclear to me why you moved from ProcessThread to > TestProcessThread + Process. An explanation of that would make it easier > to understand many of the changes. > > thanks, > > Chris > > On 7/11/19 10:16 AM, Daniil Titov wrote: > > Please review the change that fixes an intermittent failure of sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java > > test due to ports collision. The tests finds all network interfaces and for every interface starts a separate process that tests > > the connection to JMX agent server for a specific ports/interface combination. > > > > The test was changed to retry in case of the failure. If the subprocess fails to bind and the number > > of retry attempts doesn't exceed the limit a new pair of random ports is selected and the test is run again. > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8221303/webrev.01/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8221303 > > > > Thanks! > > --Daniil > > > > > > > > From chris.plummer at oracle.com Wed Jul 17 20:47:17 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 17 Jul 2019 13:47:17 -0700 Subject: jmx-dev 8221303: sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java fails due to java.rmi.server.ExportException: Port already in use In-Reply-To: <0c59c27e-c8b0-2c8d-8b3b-7bf7dc987c71@oracle.com> References: <19FCBDF1-70D7-4CC3-BFBE-945857301282@oracle.com> <070f6ca7-c235-89da-9ea1-0702027a6e34@oracle.com> <0c59c27e-c8b0-2c8d-8b3b-7bf7dc987c71@oracle.com> Message-ID: <6790692a-3c39-557d-8b5a-7cfa6658dda9@oracle.com> Hi Daniil, I think you can remove "Ok" from the following message: ?237 System.out.println("DEBUG: OK. Spawned java process terminated with expected exit code of " ?238???????????????????????? + STOP_PROCESS_EXIT_VAL); It's somewhat misleading since the test can still fail. I think the following is also misleading: ?249???????????? if (testFailed) { ?250???????????????? output.reportDiagnosticSummary(); ?251???????????????? if (output.getStderr().contains("Port already in use")) { ?252???????????????????? // Need to retry ?253???????????????????? return true; ?254???????????????? } ?255???????????? } The test can still pass after this happens, right? And I think there are other "Test FAILURE" error message that can appear just before this. Perhaps the code above should add a println that indicates that there will be a retry attempt since the failure was due to the port being in use. Otherwise looks good. thanks, Chris On 7/17/19 1:30 PM, Alex Menkov wrote: > Hi Daniil, > > The fix looks good in general. > Couple cosmetic notes (no new webrev required): > > ?162???????????????? needRetry = runTest(); > ?163???????????? } > ?164???????????? while (needRetry && (attempts++ < MAX_RETRY_ATTEMTS)); > Please move "while" to the prev line: > ?163???????????? } while (needRetry && (attempts++ < MAX_RETRY_ATTEMTS)); > > > ?242???????????????????? System.out.println("Test FAILURE on" + name + > " reason: The expected line \"" + READY_MSG > ?243???????????????????????????? + "\" is not present in the process > output"); > Please add space: "Test FAILURE on " + name > > --alex > > On 07/17/2019 12:46, Daniil Titov wrote: >> Hi Chris, >> >>> ??? It's a little unclear to me why you moved from ProcessThread to >>> ?? TestProcessThread + Process. An explanation of that would make it >>> easier >>> ?? to understand many of the changes. >> >> There are two reasons for that: >> 1)? For every network interface the test starts a separate thread >> that runs the test for this interface. We want that if the test fails >> ???? due to the bind error the thread not to exit but try to repeat >> the test several times. jdk.test.lib.thread.ProcessThread doesn't >> allow this. >> 2) To filter out the cases when the test fails due to the bind error >> we need to parse the process output. jdk.test.lib.thread.ProcessThread >> ?? registers its own pumps for stdin and sdtout? (by calling >> ProcessTools.startProcess()) that consume all output of the process >> and prevent >> ?? the output analyzer from collecting this output. >> ? Thanks! >> --Daniil >> >> ?On 7/17/19, 12:11 PM, "Chris Plummer" wrote: >> >> ???? Hi Daniil, >> ???? ???? It's a little unclear to me why you moved from >> ProcessThread to >> ???? TestProcessThread + Process. An explanation of that would make >> it easier >> ???? to understand many of the changes. >> ???? ???? thanks, >> ???? ???? Chris >> ???? ???? On 7/11/19 10:16 AM, Daniil Titov wrote: >> ???? > Please review the change that fixes an intermittent failure of >> sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java >> ???? > test due to ports collision. The tests finds all network >> interfaces and for every interface starts a separate process that tests >> ???? > the connection to JMX agent server for a specific >> ports/interface combination. >> ???? > >> ???? > The test was changed to retry in case of the failure. If the >> subprocess fails to bind and the number >> ???? > of retry attempts doesn't exceed the limit a new pair of >> random ports is selected and the test is run again. >> ???? > >> ???? > Webrev: http://cr.openjdk.java.net/~dtitov/8221303/webrev.01/ >> ???? > Bug: https://bugs.openjdk.java.net/browse/JDK-8221303 >> ???? > >> ???? > Thanks! >> ???? > --Daniil >> ???? > >> ???? > >> >> From daniil.x.titov at oracle.com Wed Jul 17 22:20:04 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Wed, 17 Jul 2019 15:20:04 -0700 Subject: jmx-dev RFR: 8221303: sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java fails due to java.rmi.server.ExportException: Port already in use Message-ID: Hi Chris and Alex, Please review a new version of the fix that moves the diagnostic output for the test failure to run() method after the number of retry attempts is exceeded. It also includes other corrections that you suggested. Thanks! Webrev: http://cr.openjdk.java.net/~dtitov/8221303/webrev.02/ Bug: https://bugs.openjdk.java.net/browse/JDK-8221303 --Best regards, Daniil ?On 7/17/19, 1:47 PM, "Chris Plummer" wrote: Hi Daniil, I think you can remove "Ok" from the following message: 237 System.out.println("DEBUG: OK. Spawned java process terminated with expected exit code of " 238 + STOP_PROCESS_EXIT_VAL); It's somewhat misleading since the test can still fail. I think the following is also misleading: 249 if (testFailed) { 250 output.reportDiagnosticSummary(); 251 if (output.getStderr().contains("Port already in use")) { 252 // Need to retry 253 return true; 254 } 255 } The test can still pass after this happens, right? And I think there are other "Test FAILURE" error message that can appear just before this. Perhaps the code above should add a println that indicates that there will be a retry attempt since the failure was due to the port being in use. Otherwise looks good. thanks, Chris On 7/17/19 1:30 PM, Alex Menkov wrote: > Hi Daniil, > > The fix looks good in general. > Couple cosmetic notes (no new webrev required): > > 162 needRetry = runTest(); > 163 } > 164 while (needRetry && (attempts++ < MAX_RETRY_ATTEMTS)); > Please move "while" to the prev line: > 163 } while (needRetry && (attempts++ < MAX_RETRY_ATTEMTS)); > > > 242 System.out.println("Test FAILURE on" + name + > " reason: The expected line \"" + READY_MSG > 243 + "\" is not present in the process > output"); > Please add space: "Test FAILURE on " + name > > --alex > > On 07/17/2019 12:46, Daniil Titov wrote: >> Hi Chris, >> >>> It's a little unclear to me why you moved from ProcessThread to >>> TestProcessThread + Process. An explanation of that would make it >>> easier >>> to understand many of the changes. >> >> There are two reasons for that: >> 1) For every network interface the test starts a separate thread >> that runs the test for this interface. We want that if the test fails >> due to the bind error the thread not to exit but try to repeat >> the test several times. jdk.test.lib.thread.ProcessThread doesn't >> allow this. >> 2) To filter out the cases when the test fails due to the bind error >> we need to parse the process output. jdk.test.lib.thread.ProcessThread >> registers its own pumps for stdin and sdtout (by calling >> ProcessTools.startProcess()) that consume all output of the process >> and prevent >> the output analyzer from collecting this output. >> Thanks! >> --Daniil >> >> ?On 7/17/19, 12:11 PM, "Chris Plummer" wrote: >> >> Hi Daniil, >> It's a little unclear to me why you moved from >> ProcessThread to >> TestProcessThread + Process. An explanation of that would make >> it easier >> to understand many of the changes. >> thanks, >> Chris >> On 7/11/19 10:16 AM, Daniil Titov wrote: >> > Please review the change that fixes an intermittent failure of >> sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java >> > test due to ports collision. The tests finds all network >> interfaces and for every interface starts a separate process that tests >> > the connection to JMX agent server for a specific >> ports/interface combination. >> > >> > The test was changed to retry in case of the failure. If the >> subprocess fails to bind and the number >> > of retry attempts doesn't exceed the limit a new pair of >> random ports is selected and the test is run again. >> > >> > Webrev: http://cr.openjdk.java.net/~dtitov/8221303/webrev.01/ >> > Bug: https://bugs.openjdk.java.net/browse/JDK-8221303 >> > >> > Thanks! >> > --Daniil >> > >> > >> >> From chris.plummer at oracle.com Wed Jul 17 22:58:56 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 17 Jul 2019 15:58:56 -0700 Subject: jmx-dev RFR: 8221303: sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java fails due to java.rmi.server.ExportException: Port already in use In-Reply-To: References: Message-ID: <660499be-e531-3bae-adb3-e89342b00af3@oracle.com> What does output.reportDiagnosticSummary() print out then the port is already in use, and have you made this happen with your fixes in place? Chris On 7/17/19 3:20 PM, Daniil Titov wrote: > Hi Chris and Alex, > > Please review a new version of the fix that moves the diagnostic output for the test failure to run() > method after the number of retry attempts is exceeded. It also includes other corrections that > you suggested. > > Thanks! > > Webrev: http://cr.openjdk.java.net/~dtitov/8221303/webrev.02/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8221303 > > --Best regards, > Daniil > > > ?On 7/17/19, 1:47 PM, "Chris Plummer" wrote: > > Hi Daniil, > > I think you can remove "Ok" from the following message: > > 237 System.out.println("DEBUG: OK. Spawned java process terminated > with expected exit code of " > 238 + STOP_PROCESS_EXIT_VAL); > > It's somewhat misleading since the test can still fail. I think the > following is also misleading: > > 249 if (testFailed) { > 250 output.reportDiagnosticSummary(); > 251 if (output.getStderr().contains("Port already in > use")) { > 252 // Need to retry > 253 return true; > 254 } > 255 } > > The test can still pass after this happens, right? And I think there are > other "Test FAILURE" error message that can appear just before this. > Perhaps the code above should add a println that indicates that there > will be a retry attempt since the failure was due to the port being in use. > > Otherwise looks good. > > thanks, > > Chris > > On 7/17/19 1:30 PM, Alex Menkov wrote: > > Hi Daniil, > > > > The fix looks good in general. > > Couple cosmetic notes (no new webrev required): > > > > 162 needRetry = runTest(); > > 163 } > > 164 while (needRetry && (attempts++ < MAX_RETRY_ATTEMTS)); > > Please move "while" to the prev line: > > 163 } while (needRetry && (attempts++ < MAX_RETRY_ATTEMTS)); > > > > > > 242 System.out.println("Test FAILURE on" + name + > > " reason: The expected line \"" + READY_MSG > > 243 + "\" is not present in the process > > output"); > > Please add space: "Test FAILURE on " + name > > > > --alex > > > > On 07/17/2019 12:46, Daniil Titov wrote: > >> Hi Chris, > >> > >>> It's a little unclear to me why you moved from ProcessThread to > >>> TestProcessThread + Process. An explanation of that would make it > >>> easier > >>> to understand many of the changes. > >> > >> There are two reasons for that: > >> 1) For every network interface the test starts a separate thread > >> that runs the test for this interface. We want that if the test fails > >> due to the bind error the thread not to exit but try to repeat > >> the test several times. jdk.test.lib.thread.ProcessThread doesn't > >> allow this. > >> 2) To filter out the cases when the test fails due to the bind error > >> we need to parse the process output. jdk.test.lib.thread.ProcessThread > >> registers its own pumps for stdin and sdtout (by calling > >> ProcessTools.startProcess()) that consume all output of the process > >> and prevent > >> the output analyzer from collecting this output. > >> Thanks! > >> --Daniil > >> > >> ?On 7/17/19, 12:11 PM, "Chris Plummer" wrote: > >> > >> Hi Daniil, > >> It's a little unclear to me why you moved from > >> ProcessThread to > >> TestProcessThread + Process. An explanation of that would make > >> it easier > >> to understand many of the changes. > >> thanks, > >> Chris > >> On 7/11/19 10:16 AM, Daniil Titov wrote: > >> > Please review the change that fixes an intermittent failure of > >> sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java > >> > test due to ports collision. The tests finds all network > >> interfaces and for every interface starts a separate process that tests > >> > the connection to JMX agent server for a specific > >> ports/interface combination. > >> > > >> > The test was changed to retry in case of the failure. If the > >> subprocess fails to bind and the number > >> > of retry attempts doesn't exceed the limit a new pair of > >> random ports is selected and the test is run again. > >> > > >> > Webrev: http://cr.openjdk.java.net/~dtitov/8221303/webrev.01/ > >> > Bug: https://bugs.openjdk.java.net/browse/JDK-8221303 > >> > > >> > Thanks! > >> > --Daniil > >> > > >> > > >> > >> > > > > From daniil.x.titov at oracle.com Wed Jul 17 23:36:11 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Wed, 17 Jul 2019 16:36:11 -0700 Subject: jmx-dev 8221303: sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java fails due to java.rmi.server.ExportException: Port already in use In-Reply-To: <660499be-e531-3bae-adb3-e89342b00af3@oracle.com> References: <660499be-e531-3bae-adb3-e89342b00af3@oracle.com> Message-ID: <032FFAEE-162D-4444-8278-66F72F578F0D@oracle.com> Hi Chris, output.reportDiagnosticSummary() prints the output from the process (both stdout and stderr) and the exit value to the test's stderr. In case if the port is already in use it prints the following: stdout: []; stderr: [Error: JMX connector server communication error: service:jmx:rmi://127.0.0.1:9101 jdk.internal.agent.AgentConfigurationError: java.rmi.server.ExportException: Port already in use: 9101; nested exception is: java.net.BindException: Address already in use at jdk.management.agent/sun.management.jmxremote.ConnectorBootstrap.exportMBeanServer(ConnectorBootstrap.java:820) at jdk.management.agent/sun.management.jmxremote.ConnectorBootstrap.startRemoteConnectorServer(ConnectorBootstrap.java:479) at jdk.management.agent/jdk.internal.agent.Agent.startAgent(Agent.java:447) at jdk.management.agent/jdk.internal.agent.Agent.startAgent(Agent.java:599) Caused by: java.rmi.server.ExportException: Port already in use: 9101; nested exception is: < I skipped the rest> ] exitValue = 1 It makes sense to have it called if the test fails, otherwise this information would be missed in the test output. Please review the new version of the fix that has the call to output.reportDiagnosticSummary() restored. Thanks! Webrev: http://cr.openjdk.java.net/~dtitov/8221303/webrev.03/ Bug: https://bugs.openjdk.java.net/browse/JDK-8221303 -Daniil ?On 7/17/19, 3:58 PM, "Chris Plummer" wrote: What does output.reportDiagnosticSummary() print out then the port is already in use, and have you made this happen with your fixes in place? Chris On 7/17/19 3:20 PM, Daniil Titov wrote: > Hi Chris and Alex, > > Please review a new version of the fix that moves the diagnostic output for the test failure to run() > method after the number of retry attempts is exceeded. It also includes other corrections that > you suggested. > > Thanks! > > Webrev: http://cr.openjdk.java.net/~dtitov/8221303/webrev.02/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8221303 > > --Best regards, > Daniil > > > ?On 7/17/19, 1:47 PM, "Chris Plummer" wrote: > > Hi Daniil, > > I think you can remove "Ok" from the following message: > > 237 System.out.println("DEBUG: OK. Spawned java process terminated > with expected exit code of " > 238 + STOP_PROCESS_EXIT_VAL); > > It's somewhat misleading since the test can still fail. I think the > following is also misleading: > > 249 if (testFailed) { > 250 output.reportDiagnosticSummary(); > 251 if (output.getStderr().contains("Port already in > use")) { > 252 // Need to retry > 253 return true; > 254 } > 255 } > > The test can still pass after this happens, right? And I think there are > other "Test FAILURE" error message that can appear just before this. > Perhaps the code above should add a println that indicates that there > will be a retry attempt since the failure was due to the port being in use. > > Otherwise looks good. > > thanks, > > Chris > > On 7/17/19 1:30 PM, Alex Menkov wrote: > > Hi Daniil, > > > > The fix looks good in general. > > Couple cosmetic notes (no new webrev required): > > > > 162 needRetry = runTest(); > > 163 } > > 164 while (needRetry && (attempts++ < MAX_RETRY_ATTEMTS)); > > Please move "while" to the prev line: > > 163 } while (needRetry && (attempts++ < MAX_RETRY_ATTEMTS)); > > > > > > 242 System.out.println("Test FAILURE on" + name + > > " reason: The expected line \"" + READY_MSG > > 243 + "\" is not present in the process > > output"); > > Please add space: "Test FAILURE on " + name > > > > --alex > > > > On 07/17/2019 12:46, Daniil Titov wrote: > >> Hi Chris, > >> > >>> It's a little unclear to me why you moved from ProcessThread to > >>> TestProcessThread + Process. An explanation of that would make it > >>> easier > >>> to understand many of the changes. > >> > >> There are two reasons for that: > >> 1) For every network interface the test starts a separate thread > >> that runs the test for this interface. We want that if the test fails > >> due to the bind error the thread not to exit but try to repeat > >> the test several times. jdk.test.lib.thread.ProcessThread doesn't > >> allow this. > >> 2) To filter out the cases when the test fails due to the bind error > >> we need to parse the process output. jdk.test.lib.thread.ProcessThread > >> registers its own pumps for stdin and sdtout (by calling > >> ProcessTools.startProcess()) that consume all output of the process > >> and prevent > >> the output analyzer from collecting this output. > >> Thanks! > >> --Daniil > >> > >> ?On 7/17/19, 12:11 PM, "Chris Plummer" wrote: > >> > >> Hi Daniil, > >> It's a little unclear to me why you moved from > >> ProcessThread to > >> TestProcessThread + Process. An explanation of that would make > >> it easier > >> to understand many of the changes. > >> thanks, > >> Chris > >> On 7/11/19 10:16 AM, Daniil Titov wrote: > >> > Please review the change that fixes an intermittent failure of > >> sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java > >> > test due to ports collision. The tests finds all network > >> interfaces and for every interface starts a separate process that tests > >> > the connection to JMX agent server for a specific > >> ports/interface combination. > >> > > >> > The test was changed to retry in case of the failure. If the > >> subprocess fails to bind and the number > >> > of retry attempts doesn't exceed the limit a new pair of > >> random ports is selected and the test is run again. > >> > > >> > Webrev: http://cr.openjdk.java.net/~dtitov/8221303/webrev.01/ > >> > Bug: https://bugs.openjdk.java.net/browse/JDK-8221303 > >> > > >> > Thanks! > >> > --Daniil > >> > > >> > > >> > >> > > > > From chris.plummer at oracle.com Thu Jul 18 00:33:04 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 17 Jul 2019 17:33:04 -0700 Subject: jmx-dev 8221303: sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java fails due to java.rmi.server.ExportException: Port already in use In-Reply-To: <032FFAEE-162D-4444-8278-66F72F578F0D@oracle.com> References: <660499be-e531-3bae-adb3-e89342b00af3@oracle.com> <032FFAEE-162D-4444-8278-66F72F578F0D@oracle.com> Message-ID: <6e763d2b-d031-e88b-1f4f-f190e9581ada@oracle.com> Hi Daniil, I'm confused now. I mentioned output.reportDiagnosticSummary() because I thought I saw it in your webrev-02. Now I don't. Maybe I had glanced back at webrev-01 and saw it there. One issue with exceptions in the output that are not considered errors is that if later there is an error, mdash wills show the exception as one of (possible multiple) reasons for the failure, so it's good to avoid if possible. Looks like what you have now is ok. I have a question about what happens if you run out of retries. What is output.getExitValue() set to? Also, I think you should print an an explicit error message indicating you've run out of retries. thanks, Chris On 7/17/19 4:36 PM, Daniil Titov wrote: > Hi Chris, > > output.reportDiagnosticSummary() prints the output from the process (both stdout and stderr) and the exit value to the test's stderr. > In case if the port is already in use it prints the following: > > stdout: []; > stderr: [Error: JMX connector server communication error: service:jmx:rmi://127.0.0.1:9101 > jdk.internal.agent.AgentConfigurationError: java.rmi.server.ExportException: Port already in use: 9101; nested exception is: > java.net.BindException: Address already in use > at jdk.management.agent/sun.management.jmxremote.ConnectorBootstrap.exportMBeanServer(ConnectorBootstrap.java:820) > at jdk.management.agent/sun.management.jmxremote.ConnectorBootstrap.startRemoteConnectorServer(ConnectorBootstrap.java:479) > at jdk.management.agent/jdk.internal.agent.Agent.startAgent(Agent.java:447) > at jdk.management.agent/jdk.internal.agent.Agent.startAgent(Agent.java:599) > Caused by: java.rmi.server.ExportException: Port already in use: 9101; nested exception is: > < I skipped the rest> > ] > exitValue = 1 > > It makes sense to have it called if the test fails, otherwise this information would be missed in the test output. > Please review the new version of the fix that has the call to output.reportDiagnosticSummary() restored. > > Thanks! > > Webrev: http://cr.openjdk.java.net/~dtitov/8221303/webrev.03/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8221303 > > -Daniil > > ?On 7/17/19, 3:58 PM, "Chris Plummer" wrote: > > What does output.reportDiagnosticSummary() print out then the port is > already in use, and have you made this happen with your fixes in place? > > Chris > > On 7/17/19 3:20 PM, Daniil Titov wrote: > > Hi Chris and Alex, > > > > Please review a new version of the fix that moves the diagnostic output for the test failure to run() > > method after the number of retry attempts is exceeded. It also includes other corrections that > > you suggested. > > > > Thanks! > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8221303/webrev.02/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8221303 > > > > --Best regards, > > Daniil > > > > > > ?On 7/17/19, 1:47 PM, "Chris Plummer" wrote: > > > > Hi Daniil, > > > > I think you can remove "Ok" from the following message: > > > > 237 System.out.println("DEBUG: OK. Spawned java process terminated > > with expected exit code of " > > 238 + STOP_PROCESS_EXIT_VAL); > > > > It's somewhat misleading since the test can still fail. I think the > > following is also misleading: > > > > 249 if (testFailed) { > > 250 output.reportDiagnosticSummary(); > > 251 if (output.getStderr().contains("Port already in > > use")) { > > 252 // Need to retry > > 253 return true; > > 254 } > > 255 } > > > > The test can still pass after this happens, right? And I think there are > > other "Test FAILURE" error message that can appear just before this. > > Perhaps the code above should add a println that indicates that there > > will be a retry attempt since the failure was due to the port being in use. > > > > Otherwise looks good. > > > > thanks, > > > > Chris > > > > On 7/17/19 1:30 PM, Alex Menkov wrote: > > > Hi Daniil, > > > > > > The fix looks good in general. > > > Couple cosmetic notes (no new webrev required): > > > > > > 162 needRetry = runTest(); > > > 163 } > > > 164 while (needRetry && (attempts++ < MAX_RETRY_ATTEMTS)); > > > Please move "while" to the prev line: > > > 163 } while (needRetry && (attempts++ < MAX_RETRY_ATTEMTS)); > > > > > > > > > 242 System.out.println("Test FAILURE on" + name + > > > " reason: The expected line \"" + READY_MSG > > > 243 + "\" is not present in the process > > > output"); > > > Please add space: "Test FAILURE on " + name > > > > > > --alex > > > > > > On 07/17/2019 12:46, Daniil Titov wrote: > > >> Hi Chris, > > >> > > >>> It's a little unclear to me why you moved from ProcessThread to > > >>> TestProcessThread + Process. An explanation of that would make it > > >>> easier > > >>> to understand many of the changes. > > >> > > >> There are two reasons for that: > > >> 1) For every network interface the test starts a separate thread > > >> that runs the test for this interface. We want that if the test fails > > >> due to the bind error the thread not to exit but try to repeat > > >> the test several times. jdk.test.lib.thread.ProcessThread doesn't > > >> allow this. > > >> 2) To filter out the cases when the test fails due to the bind error > > >> we need to parse the process output. jdk.test.lib.thread.ProcessThread > > >> registers its own pumps for stdin and sdtout (by calling > > >> ProcessTools.startProcess()) that consume all output of the process > > >> and prevent > > >> the output analyzer from collecting this output. > > >> Thanks! > > >> --Daniil > > >> > > >> ?On 7/17/19, 12:11 PM, "Chris Plummer" wrote: > > >> > > >> Hi Daniil, > > >> It's a little unclear to me why you moved from > > >> ProcessThread to > > >> TestProcessThread + Process. An explanation of that would make > > >> it easier > > >> to understand many of the changes. > > >> thanks, > > >> Chris > > >> On 7/11/19 10:16 AM, Daniil Titov wrote: > > >> > Please review the change that fixes an intermittent failure of > > >> sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java > > >> > test due to ports collision. The tests finds all network > > >> interfaces and for every interface starts a separate process that tests > > >> > the connection to JMX agent server for a specific > > >> ports/interface combination. > > >> > > > >> > The test was changed to retry in case of the failure. If the > > >> subprocess fails to bind and the number > > >> > of retry attempts doesn't exceed the limit a new pair of > > >> random ports is selected and the test is run again. > > >> > > > >> > Webrev: http://cr.openjdk.java.net/~dtitov/8221303/webrev.01/ > > >> > Bug: https://bugs.openjdk.java.net/browse/JDK-8221303 > > >> > > > >> > Thanks! > > >> > --Daniil > > >> > > > >> > > > >> > > >> > > > > > > > > > > > > > From daniil.x.titov at oracle.com Thu Jul 18 01:26:19 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Wed, 17 Jul 2019 18:26:19 -0700 Subject: jmx-dev 8221303: sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java fails due to java.rmi.server.ExportException: Port already in use In-Reply-To: <6e763d2b-d031-e88b-1f4f-f190e9581ada@oracle.com> References: <660499be-e531-3bae-adb3-e89342b00af3@oracle.com> <032FFAEE-162D-4444-8278-66F72F578F0D@oracle.com> <6e763d2b-d031-e88b-1f4f-f190e9581ada@oracle.com> Message-ID: <39DAD749-831D-4988-8216-B4A88613E6B4@oracle.com> Hi Chris, Yes, I added output.reportDiagnosticSummary() in webrev-01, but removed it In webrev-02, and later restored it in webrev-03. When the test runs of retries output.getExitValue() is set to 1 (COMMUNICATION_ERROR_EXIT_VAL) (the "exitValue =1 " in the previous email). Please review a new version of the fix that has an explicit error message printed if the test runs out of retries (line 168). Webrev: http://cr.openjdk.java.net/~dtitov/8221303/webrev.04/ Bug: https://bugs.openjdk.java.net/browse/JDK-8221303 Thanks! --Daniil ?On 7/17/19, 5:33 PM, "Chris Plummer" wrote: Hi Daniil, I'm confused now. I mentioned output.reportDiagnosticSummary() because I thought I saw it in your webrev-02. Now I don't. Maybe I had glanced back at webrev-01 and saw it there. One issue with exceptions in the output that are not considered errors is that if later there is an error, mdash wills show the exception as one of (possible multiple) reasons for the failure, so it's good to avoid if possible. Looks like what you have now is ok. I have a question about what happens if you run out of retries. What is output.getExitValue() set to? Also, I think you should print an an explicit error message indicating you've run out of retries. thanks, Chris On 7/17/19 4:36 PM, Daniil Titov wrote: > Hi Chris, > > output.reportDiagnosticSummary() prints the output from the process (both stdout and stderr) and the exit value to the test's stderr. > In case if the port is already in use it prints the following: > > stdout: []; > stderr: [Error: JMX connector server communication error: service:jmx:rmi://127.0.0.1:9101 > jdk.internal.agent.AgentConfigurationError: java.rmi.server.ExportException: Port already in use: 9101; nested exception is: > java.net.BindException: Address already in use > at jdk.management.agent/sun.management.jmxremote.ConnectorBootstrap.exportMBeanServer(ConnectorBootstrap.java:820) > at jdk.management.agent/sun.management.jmxremote.ConnectorBootstrap.startRemoteConnectorServer(ConnectorBootstrap.java:479) > at jdk.management.agent/jdk.internal.agent.Agent.startAgent(Agent.java:447) > at jdk.management.agent/jdk.internal.agent.Agent.startAgent(Agent.java:599) > Caused by: java.rmi.server.ExportException: Port already in use: 9101; nested exception is: > < I skipped the rest> > ] > exitValue = 1 > > It makes sense to have it called if the test fails, otherwise this information would be missed in the test output. > Please review the new version of the fix that has the call to output.reportDiagnosticSummary() restored. > > Thanks! > > Webrev: http://cr.openjdk.java.net/~dtitov/8221303/webrev.03/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8221303 > > -Daniil > > ?On 7/17/19, 3:58 PM, "Chris Plummer" wrote: > > What does output.reportDiagnosticSummary() print out then the port is > already in use, and have you made this happen with your fixes in place? > > Chris > > On 7/17/19 3:20 PM, Daniil Titov wrote: > > Hi Chris and Alex, > > > > Please review a new version of the fix that moves the diagnostic output for the test failure to run() > > method after the number of retry attempts is exceeded. It also includes other corrections that > > you suggested. > > > > Thanks! > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8221303/webrev.02/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8221303 > > > > --Best regards, > > Daniil > > > > > > ?On 7/17/19, 1:47 PM, "Chris Plummer" wrote: > > > > Hi Daniil, > > > > I think you can remove "Ok" from the following message: > > > > 237 System.out.println("DEBUG: OK. Spawned java process terminated > > with expected exit code of " > > 238 + STOP_PROCESS_EXIT_VAL); > > > > It's somewhat misleading since the test can still fail. I think the > > following is also misleading: > > > > 249 if (testFailed) { > > 250 output.reportDiagnosticSummary(); > > 251 if (output.getStderr().contains("Port already in > > use")) { > > 252 // Need to retry > > 253 return true; > > 254 } > > 255 } > > > > The test can still pass after this happens, right? And I think there are > > other "Test FAILURE" error message that can appear just before this. > > Perhaps the code above should add a println that indicates that there > > will be a retry attempt since the failure was due to the port being in use. > > > > Otherwise looks good. > > > > thanks, > > > > Chris > > > > On 7/17/19 1:30 PM, Alex Menkov wrote: > > > Hi Daniil, > > > > > > The fix looks good in general. > > > Couple cosmetic notes (no new webrev required): > > > > > > 162 needRetry = runTest(); > > > 163 } > > > 164 while (needRetry && (attempts++ < MAX_RETRY_ATTEMTS)); > > > Please move "while" to the prev line: > > > 163 } while (needRetry && (attempts++ < MAX_RETRY_ATTEMTS)); > > > > > > > > > 242 System.out.println("Test FAILURE on" + name + > > > " reason: The expected line \"" + READY_MSG > > > 243 + "\" is not present in the process > > > output"); > > > Please add space: "Test FAILURE on " + name > > > > > > --alex > > > > > > On 07/17/2019 12:46, Daniil Titov wrote: > > >> Hi Chris, > > >> > > >>> It's a little unclear to me why you moved from ProcessThread to > > >>> TestProcessThread + Process. An explanation of that would make it > > >>> easier > > >>> to understand many of the changes. > > >> > > >> There are two reasons for that: > > >> 1) For every network interface the test starts a separate thread > > >> that runs the test for this interface. We want that if the test fails > > >> due to the bind error the thread not to exit but try to repeat > > >> the test several times. jdk.test.lib.thread.ProcessThread doesn't > > >> allow this. > > >> 2) To filter out the cases when the test fails due to the bind error > > >> we need to parse the process output. jdk.test.lib.thread.ProcessThread > > >> registers its own pumps for stdin and sdtout (by calling > > >> ProcessTools.startProcess()) that consume all output of the process > > >> and prevent > > >> the output analyzer from collecting this output. > > >> Thanks! > > >> --Daniil > > >> > > >> ?On 7/17/19, 12:11 PM, "Chris Plummer" wrote: > > >> > > >> Hi Daniil, > > >> It's a little unclear to me why you moved from > > >> ProcessThread to > > >> TestProcessThread + Process. An explanation of that would make > > >> it easier > > >> to understand many of the changes. > > >> thanks, > > >> Chris > > >> On 7/11/19 10:16 AM, Daniil Titov wrote: > > >> > Please review the change that fixes an intermittent failure of > > >> sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java > > >> > test due to ports collision. The tests finds all network > > >> interfaces and for every interface starts a separate process that tests > > >> > the connection to JMX agent server for a specific > > >> ports/interface combination. > > >> > > > >> > The test was changed to retry in case of the failure. If the > > >> subprocess fails to bind and the number > > >> > of retry attempts doesn't exceed the limit a new pair of > > >> random ports is selected and the test is run again. > > >> > > > >> > Webrev: http://cr.openjdk.java.net/~dtitov/8221303/webrev.01/ > > >> > Bug: https://bugs.openjdk.java.net/browse/JDK-8221303 > > >> > > > >> > Thanks! > > >> > --Daniil > > >> > > > >> > > > >> > > >> > > > > > > > > > > > > > From sgehwolf at redhat.com Thu Jul 18 08:13:18 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 18 Jul 2019 10:13:18 +0200 Subject: jmx-dev 8221303: sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java fails due to java.rmi.server.ExportException: Port already in use In-Reply-To: <39DAD749-831D-4988-8216-B4A88613E6B4@oracle.com> References: <660499be-e531-3bae-adb3-e89342b00af3@oracle.com> <032FFAEE-162D-4444-8278-66F72F578F0D@oracle.com> <6e763d2b-d031-e88b-1f4f-f190e9581ada@oracle.com> <39DAD749-831D-4988-8216-B4A88613E6B4@oracle.com> Message-ID: Hi Daniil, On Wed, 2019-07-17 at 18:26 -0700, Daniil Titov wrote: > Hi Chris, > > Yes, I added output.reportDiagnosticSummary() in webrev-01, but removed it > In webrev-02, and later restored it in webrev-03. > > When the test runs of retries output.getExitValue() is set to 1 (COMMUNICATION_ERROR_EXIT_VAL) > (the "exitValue =1 " in the previous email). > > Please review a new version of the fix that has an explicit error message printed > if the test runs out of retries (line 168). > > Webrev: http://cr.openjdk.java.net/~dtitov/8221303/webrev.04/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8221303 This looks reasonable to me. Thanks for fixing it! Thanks, Severin > Thanks! > --Daniil > > ?On 7/17/19, 5:33 PM, "Chris Plummer" > wrote: > > Hi Daniil, > > I'm confused now. I mentioned output.reportDiagnosticSummary() > because I > thought I saw it in your webrev-02. Now I don't. Maybe I had > glanced > back at webrev-01 and saw it there. One issue with exceptions in > the > output that are not considered errors is that if later there is > an > error, mdash wills show the exception as one of (possible > multiple) > reasons for the failure, so it's good to avoid if possible. Looks > like > what you have now is ok. > > I have a question about what happens if you run out of retries. > What is > output.getExitValue() set to? Also, I think you should print an > an > explicit error message indicating you've run out of retries. > > thanks, > > Chris > > On 7/17/19 4:36 PM, Daniil Titov wrote: > > Hi Chris, > > > > output.reportDiagnosticSummary() prints the output from the > process (both stdout and stderr) and the exit value to the test's > stderr. > > In case if the port is already in use it prints the following: > > > > stdout: []; > > stderr: [Error: JMX connector server communication error: > service:jmx:rmi://127.0.0.1:9101 > > jdk.internal.agent.AgentConfigurationError: > java.rmi.server.ExportException: Port already in use: 9101; nested > exception is: > > java.net.BindException: Address already in use > > at > jdk.management.agent/sun.management.jmxremote.ConnectorBootstrap.expo > rtMBeanServer(ConnectorBootstrap.java:820) > > at > jdk.management.agent/sun.management.jmxremote.ConnectorBootstrap.star > tRemoteConnectorServer(ConnectorBootstrap.java:479) > > at > jdk.management.agent/jdk.internal.agent.Agent.startAgent(Agent.java:4 > 47) > > at > jdk.management.agent/jdk.internal.agent.Agent.startAgent(Agent.java:5 > 99) > > Caused by: java.rmi.server.ExportException: Port already in > use: 9101; nested exception is: > > < I skipped the rest> > > ] > > exitValue = 1 > > > > It makes sense to have it called if the test fails, otherwise > this information would be missed in the test output. > > Please review the new version of the fix that has the call to > output.reportDiagnosticSummary() restored. > > > > Thanks! > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8221303/webrev.03/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8221303 > > > > -Daniil > > > > ?On 7/17/19, 3:58 PM, "Chris Plummer" > wrote: > > > > What does output.reportDiagnosticSummary() print out then > the port is > > already in use, and have you made this happen with your > fixes in place? > > > > Chris > > > > On 7/17/19 3:20 PM, Daniil Titov wrote: > > > Hi Chris and Alex, > > > > > > Please review a new version of the fix that moves the > diagnostic output for the test failure to run() > > > method after the number of retry attempts is exceeded. > It also includes other corrections that > > > you suggested. > > > > > > Thanks! > > > > > > Webrev: > http://cr.openjdk.java.net/~dtitov/8221303/webrev.02/ > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8221303 > > > > > > --Best regards, > > > Daniil > > > > > > > > > ?On 7/17/19, 1:47 PM, "Chris Plummer" < > chris.plummer at oracle.com> wrote: > > > > > > Hi Daniil, > > > > > > I think you can remove "Ok" from the following > message: > > > > > > 237 System.out.println("DEBUG: OK. Spawned java > process terminated > > > with expected exit code of " > > > 238 + > STOP_PROCESS_EXIT_VAL); > > > > > > It's somewhat misleading since the test can still > fail. I think the > > > following is also misleading: > > > > > > 249 if (testFailed) { > > > 250 output.reportDiagnosticSummar > y(); > > > 251 if > (output.getStderr().contains("Port already in > > > use")) { > > > 252 // Need to retry > > > 253 return true; > > > 254 } > > > 255 } > > > > > > The test can still pass after this happens, right? > And I think there are > > > other "Test FAILURE" error message that can appear > just before this. > > > Perhaps the code above should add a println that > indicates that there > > > will be a retry attempt since the failure was due > to the port being in use. > > > > > > Otherwise looks good. > > > > > > thanks, > > > > > > Chris > > > > > > On 7/17/19 1:30 PM, Alex Menkov wrote: > > > > Hi Daniil, > > > > > > > > The fix looks good in general. > > > > Couple cosmetic notes (no new webrev required): > > > > > > > > 162 needRetry = runTest(); > > > > 163 } > > > > 164 while (needRetry && (attempts++ > < MAX_RETRY_ATTEMTS)); > > > > Please move "while" to the prev line: > > > > 163 } while (needRetry && > (attempts++ < MAX_RETRY_ATTEMTS)); > > > > > > > > > > > > 242 System.out.println("Test > FAILURE on" + name + > > > > " reason: The expected line \"" + READY_MSG > > > > 243 + "\" is not > present in the process > > > > output"); > > > > Please add space: "Test FAILURE on " + name > > > > > > > > --alex > > > > > > > > On 07/17/2019 12:46, Daniil Titov wrote: > > > >> Hi Chris, > > > >> > > > >>> It's a little unclear to me why you moved > from ProcessThread to > > > >>> TestProcessThread + Process. An explanation > of that would make it > > > >>> easier > > > >>> to understand many of the changes. > > > >> > > > >> There are two reasons for that: > > > >> 1) For every network interface the test starts > a separate thread > > > >> that runs the test for this interface. We want > that if the test fails > > > >> due to the bind error the thread not to > exit but try to repeat > > > >> the test several times. > jdk.test.lib.thread.ProcessThread doesn't > > > >> allow this. > > > >> 2) To filter out the cases when the test fails > due to the bind error > > > >> we need to parse the process output. > jdk.test.lib.thread.ProcessThread > > > >> registers its own pumps for stdin and > sdtout (by calling > > > >> ProcessTools.startProcess()) that consume all > output of the process > > > >> and prevent > > > >> the output analyzer from collecting this > output. > > > >> Thanks! > > > >> --Daniil > > > >> > > > >> ?On 7/17/19, 12:11 PM, "Chris Plummer" < > chris.plummer at oracle.com> wrote: > > > >> > > > >> Hi Daniil, > > > >> It's a little unclear to me why you > moved from > > > >> ProcessThread to > > > >> TestProcessThread + Process. An explanation > of that would make > > > >> it easier > > > >> to understand many of the changes. > > > >> thanks, > > > >> Chris > > > >> On 7/11/19 10:16 AM, Daniil Titov > wrote: > > > >> > Please review the change that fixes an > intermittent failure of > > > >> > sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java > > > >> > test due to ports collision. The tests > finds all network > > > >> interfaces and for every interface starts a > separate process that tests > > > >> > the connection to JMX agent server for a > specific > > > >> ports/interface combination. > > > >> > > > > >> > The test was changed to retry in case of > the failure. If the > > > >> subprocess fails to bind and the number > > > >> > of retry attempts doesn't exceed the > limit a new pair of > > > >> random ports is selected and the test is run > again. > > > >> > > > > >> > Webrev: > http://cr.openjdk.java.net/~dtitov/8221303/webrev.01/ > > > >> > Bug: > https://bugs.openjdk.java.net/browse/JDK-8221303 > > > >> > > > > >> > Thanks! > > > >> > --Daniil > > > >> > > > > >> > > > > >> > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > From chris.plummer at oracle.com Thu Jul 18 15:27:21 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 18 Jul 2019 08:27:21 -0700 Subject: jmx-dev 8221303: sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java fails due to java.rmi.server.ExportException: Port already in use In-Reply-To: <39DAD749-831D-4988-8216-B4A88613E6B4@oracle.com> References: <660499be-e531-3bae-adb3-e89342b00af3@oracle.com> <032FFAEE-162D-4444-8278-66F72F578F0D@oracle.com> <6e763d2b-d031-e88b-1f4f-f190e9581ada@oracle.com> <39DAD749-831D-4988-8216-B4A88613E6B4@oracle.com> Message-ID: <3df10caa-c71e-e23c-308c-d1883b6e4222@oracle.com> Hi Daniil, Looks good. Chris On 7/17/19 6:26 PM, Daniil Titov wrote: > Hi Chris, > > Yes, I added output.reportDiagnosticSummary() in webrev-01, but removed it > In webrev-02, and later restored it in webrev-03. > > When the test runs of retries output.getExitValue() is set to 1 (COMMUNICATION_ERROR_EXIT_VAL) > (the "exitValue =1 " in the previous email). > > Please review a new version of the fix that has an explicit error message printed > if the test runs out of retries (line 168). > > Webrev: http://cr.openjdk.java.net/~dtitov/8221303/webrev.04/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8221303 > > Thanks! > --Daniil > > ?On 7/17/19, 5:33 PM, "Chris Plummer" wrote: > > Hi Daniil, > > I'm confused now. I mentioned output.reportDiagnosticSummary() because I > thought I saw it in your webrev-02. Now I don't. Maybe I had glanced > back at webrev-01 and saw it there. One issue with exceptions in the > output that are not considered errors is that if later there is an > error, mdash wills show the exception as one of (possible multiple) > reasons for the failure, so it's good to avoid if possible. Looks like > what you have now is ok. > > I have a question about what happens if you run out of retries. What is > output.getExitValue() set to? Also, I think you should print an an > explicit error message indicating you've run out of retries. > > thanks, > > Chris > > On 7/17/19 4:36 PM, Daniil Titov wrote: > > Hi Chris, > > > > output.reportDiagnosticSummary() prints the output from the process (both stdout and stderr) and the exit value to the test's stderr. > > In case if the port is already in use it prints the following: > > > > stdout: []; > > stderr: [Error: JMX connector server communication error: service:jmx:rmi://127.0.0.1:9101 > > jdk.internal.agent.AgentConfigurationError: java.rmi.server.ExportException: Port already in use: 9101; nested exception is: > > java.net.BindException: Address already in use > > at jdk.management.agent/sun.management.jmxremote.ConnectorBootstrap.exportMBeanServer(ConnectorBootstrap.java:820) > > at jdk.management.agent/sun.management.jmxremote.ConnectorBootstrap.startRemoteConnectorServer(ConnectorBootstrap.java:479) > > at jdk.management.agent/jdk.internal.agent.Agent.startAgent(Agent.java:447) > > at jdk.management.agent/jdk.internal.agent.Agent.startAgent(Agent.java:599) > > Caused by: java.rmi.server.ExportException: Port already in use: 9101; nested exception is: > > < I skipped the rest> > > ] > > exitValue = 1 > > > > It makes sense to have it called if the test fails, otherwise this information would be missed in the test output. > > Please review the new version of the fix that has the call to output.reportDiagnosticSummary() restored. > > > > Thanks! > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8221303/webrev.03/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8221303 > > > > -Daniil > > > > ?On 7/17/19, 3:58 PM, "Chris Plummer" wrote: > > > > What does output.reportDiagnosticSummary() print out then the port is > > already in use, and have you made this happen with your fixes in place? > > > > Chris > > > > On 7/17/19 3:20 PM, Daniil Titov wrote: > > > Hi Chris and Alex, > > > > > > Please review a new version of the fix that moves the diagnostic output for the test failure to run() > > > method after the number of retry attempts is exceeded. It also includes other corrections that > > > you suggested. > > > > > > Thanks! > > > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8221303/webrev.02/ > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8221303 > > > > > > --Best regards, > > > Daniil > > > > > > > > > ?On 7/17/19, 1:47 PM, "Chris Plummer" wrote: > > > > > > Hi Daniil, > > > > > > I think you can remove "Ok" from the following message: > > > > > > 237 System.out.println("DEBUG: OK. Spawned java process terminated > > > with expected exit code of " > > > 238 + STOP_PROCESS_EXIT_VAL); > > > > > > It's somewhat misleading since the test can still fail. I think the > > > following is also misleading: > > > > > > 249 if (testFailed) { > > > 250 output.reportDiagnosticSummary(); > > > 251 if (output.getStderr().contains("Port already in > > > use")) { > > > 252 // Need to retry > > > 253 return true; > > > 254 } > > > 255 } > > > > > > The test can still pass after this happens, right? And I think there are > > > other "Test FAILURE" error message that can appear just before this. > > > Perhaps the code above should add a println that indicates that there > > > will be a retry attempt since the failure was due to the port being in use. > > > > > > Otherwise looks good. > > > > > > thanks, > > > > > > Chris > > > > > > On 7/17/19 1:30 PM, Alex Menkov wrote: > > > > Hi Daniil, > > > > > > > > The fix looks good in general. > > > > Couple cosmetic notes (no new webrev required): > > > > > > > > 162 needRetry = runTest(); > > > > 163 } > > > > 164 while (needRetry && (attempts++ < MAX_RETRY_ATTEMTS)); > > > > Please move "while" to the prev line: > > > > 163 } while (needRetry && (attempts++ < MAX_RETRY_ATTEMTS)); > > > > > > > > > > > > 242 System.out.println("Test FAILURE on" + name + > > > > " reason: The expected line \"" + READY_MSG > > > > 243 + "\" is not present in the process > > > > output"); > > > > Please add space: "Test FAILURE on " + name > > > > > > > > --alex > > > > > > > > On 07/17/2019 12:46, Daniil Titov wrote: > > > >> Hi Chris, > > > >> > > > >>> It's a little unclear to me why you moved from ProcessThread to > > > >>> TestProcessThread + Process. An explanation of that would make it > > > >>> easier > > > >>> to understand many of the changes. > > > >> > > > >> There are two reasons for that: > > > >> 1) For every network interface the test starts a separate thread > > > >> that runs the test for this interface. We want that if the test fails > > > >> due to the bind error the thread not to exit but try to repeat > > > >> the test several times. jdk.test.lib.thread.ProcessThread doesn't > > > >> allow this. > > > >> 2) To filter out the cases when the test fails due to the bind error > > > >> we need to parse the process output. jdk.test.lib.thread.ProcessThread > > > >> registers its own pumps for stdin and sdtout (by calling > > > >> ProcessTools.startProcess()) that consume all output of the process > > > >> and prevent > > > >> the output analyzer from collecting this output. > > > >> Thanks! > > > >> --Daniil > > > >> > > > >> ?On 7/17/19, 12:11 PM, "Chris Plummer" wrote: > > > >> > > > >> Hi Daniil, > > > >> It's a little unclear to me why you moved from > > > >> ProcessThread to > > > >> TestProcessThread + Process. An explanation of that would make > > > >> it easier > > > >> to understand many of the changes. > > > >> thanks, > > > >> Chris > > > >> On 7/11/19 10:16 AM, Daniil Titov wrote: > > > >> > Please review the change that fixes an intermittent failure of > > > >> sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java > > > >> > test due to ports collision. The tests finds all network > > > >> interfaces and for every interface starts a separate process that tests > > > >> > the connection to JMX agent server for a specific > > > >> ports/interface combination. > > > >> > > > > >> > The test was changed to retry in case of the failure. If the > > > >> subprocess fails to bind and the number > > > >> > of retry attempts doesn't exceed the limit a new pair of > > > >> random ports is selected and the test is run again. > > > >> > > > > >> > Webrev: http://cr.openjdk.java.net/~dtitov/8221303/webrev.01/ > > > >> > Bug: https://bugs.openjdk.java.net/browse/JDK-8221303 > > > >> > > > > >> > Thanks! > > > >> > --Daniil > > > >> > > > > >> > > > > >> > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > From alexey.menkov at oracle.com Thu Jul 18 17:44:05 2019 From: alexey.menkov at oracle.com (Alex Menkov) Date: Thu, 18 Jul 2019 10:44:05 -0700 Subject: jmx-dev 8221303: sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java fails due to java.rmi.server.ExportException: Port already in use In-Reply-To: <3df10caa-c71e-e23c-308c-d1883b6e4222@oracle.com> References: <660499be-e531-3bae-adb3-e89342b00af3@oracle.com> <032FFAEE-162D-4444-8278-66F72F578F0D@oracle.com> <6e763d2b-d031-e88b-1f4f-f190e9581ada@oracle.com> <39DAD749-831D-4988-8216-B4A88613E6B4@oracle.com> <3df10caa-c71e-e23c-308c-d1883b6e4222@oracle.com> Message-ID: +1 --alex On 07/18/2019 08:27, Chris Plummer wrote: > Hi Daniil, > > Looks good. > > Chris > > On 7/17/19 6:26 PM, Daniil Titov wrote: >> Hi Chris, >> >> Yes, I added output.reportDiagnosticSummary() in webrev-01, but >> removed it >> In webrev-02, and later restored it in webrev-03. >> >> When the test runs of retries output.getExitValue() is set to 1 >> (COMMUNICATION_ERROR_EXIT_VAL) >> ? (the "exitValue =1 " in the previous email). >> >> Please review a new version of the fix that has an explicit error >> message printed >> if the test runs out of retries (line 168). >> >> Webrev: http://cr.openjdk.java.net/~dtitov/8221303/webrev.04/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8221303 >> >> Thanks! >> --Daniil >> >> ?On 7/17/19, 5:33 PM, "Chris Plummer" wrote: >> >> ???? Hi Daniil, >> ???? I'm confused now. I mentioned output.reportDiagnosticSummary() >> because I >> ???? thought I saw it in your webrev-02. Now I don't. Maybe I had glanced >> ???? back at webrev-01 and saw it there. One issue with exceptions in the >> ???? output that are not considered errors is that if later there is an >> ???? error, mdash wills show the exception as one of (possible multiple) >> ???? reasons for the failure, so it's good to avoid if possible. Looks >> like >> ???? what you have now is ok. >> ???? I have a question about what happens if you run out of retries. >> What is >> ???? output.getExitValue() set to? Also, I think you should print an an >> ???? explicit error message indicating you've run out of retries. >> ???? thanks, >> ???? Chris >> ???? On 7/17/19 4:36 PM, Daniil Titov wrote: >> ???? > Hi Chris, >> ???? > >> ???? > output.reportDiagnosticSummary() prints the output from the >> process (both stdout and stderr) and the exit value to the test's stderr. >> ???? > In case if the port is already in use it prints the following: >> ???? > >> ???? > stdout: []; >> ???? >?? stderr: [Error: JMX connector server communication error: >> service:jmx:rmi://127.0.0.1:9101 >> ???? > jdk.internal.agent.AgentConfigurationError: >> java.rmi.server.ExportException: Port already in use: 9101; nested >> exception is: >> ???? >???? java.net.BindException: Address already in use >> ???? >???? at >> jdk.management.agent/sun.management.jmxremote.ConnectorBootstrap.exportMBeanServer(ConnectorBootstrap.java:820) >> >> ???? >???? at >> jdk.management.agent/sun.management.jmxremote.ConnectorBootstrap.startRemoteConnectorServer(ConnectorBootstrap.java:479) >> >> ???? >???? at >> jdk.management.agent/jdk.internal.agent.Agent.startAgent(Agent.java:447) >> ???? >???? at >> jdk.management.agent/jdk.internal.agent.Agent.startAgent(Agent.java:599) >> ???? > Caused by: java.rmi.server.ExportException: Port already in >> use: 9101; nested exception is: >> ???? > < I skipped the rest> >> ???? > ] >> ???? >?? exitValue = 1 >> ???? > >> ???? > It makes sense to have it called if the test fails, otherwise >> this information would be missed in the test output. >> ???? > Please review the new version of the fix that has the call to >> output.reportDiagnosticSummary() restored. >> ???? > >> ???? > Thanks! >> ???? > >> ???? > Webrev: http://cr.openjdk.java.net/~dtitov/8221303/webrev.03/ >> ???? > Bug: https://bugs.openjdk.java.net/browse/JDK-8221303 >> ???? > >> ???? > -Daniil >> ???? > >> ???? > ?On 7/17/19, 3:58 PM, "Chris Plummer" >> wrote: >> ???? > >> ???? >????? What does output.reportDiagnosticSummary() print out then >> the port is >> ???? >????? already in use, and have you made this happen with your >> fixes in place? >> ???? > >> ???? >????? Chris >> ???? > >> ???? >????? On 7/17/19 3:20 PM, Daniil Titov wrote: >> ???? >????? > Hi Chris and Alex, >> ???? >????? > >> ???? >????? > Please review a new version of the fix that moves the >> diagnostic output for the test failure to run() >> ???? >????? > method after the number of retry attempts is exceeded. >> It also includes other corrections that >> ???? >????? > you suggested. >> ???? >????? > >> ???? >????? > Thanks! >> ???? >????? > >> ???? >????? > Webrev: >> http://cr.openjdk.java.net/~dtitov/8221303/webrev.02/ >> ???? >????? > Bug: https://bugs.openjdk.java.net/browse/JDK-8221303 >> ???? >????? > >> ???? >????? > --Best regards, >> ???? >????? > Daniil >> ???? >????? > >> ???? >????? > >> ???? >????? > ?On 7/17/19, 1:47 PM, "Chris Plummer" >> wrote: >> ???? >????? > >> ???? >????? >????? Hi Daniil, >> ???? >????? > >> ???? >????? >????? I think you can remove "Ok" from the following >> message: >> ???? >????? > >> ???? >????? >??????? 237 System.out.println("DEBUG: OK. Spawned java >> process terminated >> ???? >????? >????? with expected exit code of " >> ???? >????? >??????? 238???????????????????????? + >> STOP_PROCESS_EXIT_VAL); >> ???? >????? > >> ???? >????? >????? It's somewhat misleading since the test can still >> fail. I think the >> ???? >????? >????? following is also misleading: >> ???? >????? > >> ???? >????? >??????? 249???????????? if (testFailed) { >> ???? >????? >??????? 250 >> output.reportDiagnosticSummary(); >> ???? >????? >??????? 251???????????????? if >> (output.getStderr().contains("Port already in >> ???? >????? >????? use")) { >> ???? >????? >??????? 252???????????????????? // Need to retry >> ???? >????? >??????? 253???????????????????? return true; >> ???? >????? >??????? 254???????????????? } >> ???? >????? >??????? 255???????????? } >> ???? >????? > >> ???? >????? >????? The test can still pass after this happens, right? >> And I think there are >> ???? >????? >????? other "Test FAILURE" error message that can appear >> just before this. >> ???? >????? >????? Perhaps the code above should add a println that >> indicates that there >> ???? >????? >????? will be a retry attempt since the failure was due >> to the port being in use. >> ???? >????? > >> ???? >????? >????? Otherwise looks good. >> ???? >????? > >> ???? >????? >????? thanks, >> ???? >????? > >> ???? >????? >????? Chris >> ???? >????? > >> ???? >????? >????? On 7/17/19 1:30 PM, Alex Menkov wrote: >> ???? >????? >????? > Hi Daniil, >> ???? >????? >????? > >> ???? >????? >????? > The fix looks good in general. >> ???? >????? >????? > Couple cosmetic notes (no new webrev required): >> ???? >????? >????? > >> ???? >????? >????? >? 162???????????????? needRetry = runTest(); >> ???? >????? >????? >? 163???????????? } >> ???? >????? >????? >? 164???????????? while (needRetry && (attempts++ >> < MAX_RETRY_ATTEMTS)); >> ???? >????? >????? > Please move "while" to the prev line: >> ???? >????? >????? >? 163???????????? } while (needRetry && >> (attempts++ < MAX_RETRY_ATTEMTS)); >> ???? >????? >????? > >> ???? >????? >????? > >> ???? >????? >????? >? 242???????????????????? System.out.println("Test >> FAILURE on" + name + >> ???? >????? >????? > " reason: The expected line \"" + READY_MSG >> ???? >????? >????? >? 243???????????????????????????? + "\" is not >> present in the process >> ???? >????? >????? > output"); >> ???? >????? >????? > Please add space: "Test FAILURE on " + name >> ???? >????? >????? > >> ???? >????? >????? > --alex >> ???? >????? >????? > >> ???? >????? >????? > On 07/17/2019 12:46, Daniil Titov wrote: >> ???? >????? >????? >> Hi Chris, >> ???? >????? >????? >> >> ???? >????? >????? >>>???? It's a little unclear to me why you moved >> from ProcessThread to >> ???? >????? >????? >>>??? TestProcessThread + Process. An explanation >> of that would make it >> ???? >????? >????? >>> easier >> ???? >????? >????? >>>??? to understand many of the changes. >> ???? >????? >????? >> >> ???? >????? >????? >> There are two reasons for that: >> ???? >????? >????? >> 1)? For every network interface the test starts >> a separate thread >> ???? >????? >????? >> that runs the test for this interface. We want >> that if the test fails >> ???? >????? >????? >>????? due to the bind error the thread not to >> exit but try to repeat >> ???? >????? >????? >> the test several times. >> jdk.test.lib.thread.ProcessThread doesn't >> ???? >????? >????? >> allow this. >> ???? >????? >????? >> 2) To filter out the cases when the test fails >> due to the bind error >> ???? >????? >????? >> we need to parse the process output. >> jdk.test.lib.thread.ProcessThread >> ???? >????? >????? >>??? registers its own pumps for stdin and sdtout >> (by calling >> ???? >????? >????? >> ProcessTools.startProcess()) that consume all >> output of the process >> ???? >????? >????? >> and prevent >> ???? >????? >????? >>??? the output analyzer from collecting this output. >> ???? >????? >????? >>?? Thanks! >> ???? >????? >????? >> --Daniil >> ???? >????? >????? >> >> ???? >????? >????? >> ?On 7/17/19, 12:11 PM, "Chris Plummer" >> wrote: >> ???? >????? >????? >> >> ???? >????? >????? >>????? Hi Daniil, >> ???? >????? >????? >>?????????? It's a little unclear to me why you >> moved from >> ???? >????? >????? >> ProcessThread to >> ???? >????? >????? >>????? TestProcessThread + Process. An explanation >> of that would make >> ???? >????? >????? >> it easier >> ???? >????? >????? >>????? to understand many of the changes. >> ???? >????? >????? >>?????????? thanks, >> ???? >????? >????? >>?????????? Chris >> ???? >????? >????? >>?????????? On 7/11/19 10:16 AM, Daniil Titov wrote: >> ???? >????? >????? >>????? > Please review the change that fixes an >> intermittent failure of >> ???? >????? >????? >> >> sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java >> ???? >????? >????? >>????? > test due to ports collision. The tests >> finds all network >> ???? >????? >????? >> interfaces and for every interface starts a >> separate process that tests >> ???? >????? >????? >>????? > the connection to JMX agent server for a >> specific >> ???? >????? >????? >> ports/interface combination. >> ???? >????? >????? >>????? > >> ???? >????? >????? >>????? > The test was changed to retry in case of >> the failure. If the >> ???? >????? >????? >> subprocess fails to bind and the number >> ???? >????? >????? >>????? > of retry attempts doesn't exceed the >> limit a new pair of >> ???? >????? >????? >> random ports is selected and the test is run again. >> ???? >????? >????? >>????? > >> ???? >????? >????? >>????? > Webrev: >> http://cr.openjdk.java.net/~dtitov/8221303/webrev.01/ >> ???? >????? >????? >>????? > Bug: >> https://bugs.openjdk.java.net/browse/JDK-8221303 >> ???? >????? >????? >>????? > >> ???? >????? >????? >>????? > Thanks! >> ???? >????? >????? >>????? > --Daniil >> ???? >????? >????? >>????? > >> ???? >????? >????? >>????? > >> ???? >????? >????? >> >> ???? >????? >????? >> >> ???? >????? > >> ???? >????? > >> ???? >????? > >> ???? >????? > >> ???? > >> ???? > >> ???? > >> ???? > >> ???? > >> >> > > From daniil.x.titov at oracle.com Thu Jul 18 19:29:36 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Thu, 18 Jul 2019 12:29:36 -0700 Subject: jmx-dev 8221303: sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java fails due to java.rmi.server.ExportException: Port already in use In-Reply-To: References: <660499be-e531-3bae-adb3-e89342b00af3@oracle.com> <032FFAEE-162D-4444-8278-66F72F578F0D@oracle.com> <6e763d2b-d031-e88b-1f4f-f190e9581ada@oracle.com> <39DAD749-831D-4988-8216-B4A88613E6B4@oracle.com> <3df10caa-c71e-e23c-308c-d1883b6e4222@oracle.com> Message-ID: <98E57466-C89A-4555-B510-2D947F89E6B3@oracle.com> Thank you, Chris, Severin, and Alex, for reviewing this change! Best regards, Daniil ?On 7/18/19, 10:44 AM, "Alex Menkov" wrote: +1 --alex On 07/18/2019 08:27, Chris Plummer wrote: > Hi Daniil, > > Looks good. > > Chris > > On 7/17/19 6:26 PM, Daniil Titov wrote: >> Hi Chris, >> >> Yes, I added output.reportDiagnosticSummary() in webrev-01, but >> removed it >> In webrev-02, and later restored it in webrev-03. >> >> When the test runs of retries output.getExitValue() is set to 1 >> (COMMUNICATION_ERROR_EXIT_VAL) >> (the "exitValue =1 " in the previous email). >> >> Please review a new version of the fix that has an explicit error >> message printed >> if the test runs out of retries (line 168). >> >> Webrev: http://cr.openjdk.java.net/~dtitov/8221303/webrev.04/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8221303 >> >> Thanks! >> --Daniil >> >> ?On 7/17/19, 5:33 PM, "Chris Plummer" wrote: >> >> Hi Daniil, >> I'm confused now. I mentioned output.reportDiagnosticSummary() >> because I >> thought I saw it in your webrev-02. Now I don't. Maybe I had glanced >> back at webrev-01 and saw it there. One issue with exceptions in the >> output that are not considered errors is that if later there is an >> error, mdash wills show the exception as one of (possible multiple) >> reasons for the failure, so it's good to avoid if possible. Looks >> like >> what you have now is ok. >> I have a question about what happens if you run out of retries. >> What is >> output.getExitValue() set to? Also, I think you should print an an >> explicit error message indicating you've run out of retries. >> thanks, >> Chris >> On 7/17/19 4:36 PM, Daniil Titov wrote: >> > Hi Chris, >> > >> > output.reportDiagnosticSummary() prints the output from the >> process (both stdout and stderr) and the exit value to the test's stderr. >> > In case if the port is already in use it prints the following: >> > >> > stdout: []; >> > stderr: [Error: JMX connector server communication error: >> service:jmx:rmi://127.0.0.1:9101 >> > jdk.internal.agent.AgentConfigurationError: >> java.rmi.server.ExportException: Port already in use: 9101; nested >> exception is: >> > java.net.BindException: Address already in use >> > at >> jdk.management.agent/sun.management.jmxremote.ConnectorBootstrap.exportMBeanServer(ConnectorBootstrap.java:820) >> >> > at >> jdk.management.agent/sun.management.jmxremote.ConnectorBootstrap.startRemoteConnectorServer(ConnectorBootstrap.java:479) >> >> > at >> jdk.management.agent/jdk.internal.agent.Agent.startAgent(Agent.java:447) >> > at >> jdk.management.agent/jdk.internal.agent.Agent.startAgent(Agent.java:599) >> > Caused by: java.rmi.server.ExportException: Port already in >> use: 9101; nested exception is: >> > < I skipped the rest> >> > ] >> > exitValue = 1 >> > >> > It makes sense to have it called if the test fails, otherwise >> this information would be missed in the test output. >> > Please review the new version of the fix that has the call to >> output.reportDiagnosticSummary() restored. >> > >> > Thanks! >> > >> > Webrev: http://cr.openjdk.java.net/~dtitov/8221303/webrev.03/ >> > Bug: https://bugs.openjdk.java.net/browse/JDK-8221303 >> > >> > -Daniil >> > >> > ?On 7/17/19, 3:58 PM, "Chris Plummer" >> wrote: >> > >> > What does output.reportDiagnosticSummary() print out then >> the port is >> > already in use, and have you made this happen with your >> fixes in place? >> > >> > Chris >> > >> > On 7/17/19 3:20 PM, Daniil Titov wrote: >> > > Hi Chris and Alex, >> > > >> > > Please review a new version of the fix that moves the >> diagnostic output for the test failure to run() >> > > method after the number of retry attempts is exceeded. >> It also includes other corrections that >> > > you suggested. >> > > >> > > Thanks! >> > > >> > > Webrev: >> http://cr.openjdk.java.net/~dtitov/8221303/webrev.02/ >> > > Bug: https://bugs.openjdk.java.net/browse/JDK-8221303 >> > > >> > > --Best regards, >> > > Daniil >> > > >> > > >> > > ?On 7/17/19, 1:47 PM, "Chris Plummer" >> wrote: >> > > >> > > Hi Daniil, >> > > >> > > I think you can remove "Ok" from the following >> message: >> > > >> > > 237 System.out.println("DEBUG: OK. Spawned java >> process terminated >> > > with expected exit code of " >> > > 238 + >> STOP_PROCESS_EXIT_VAL); >> > > >> > > It's somewhat misleading since the test can still >> fail. I think the >> > > following is also misleading: >> > > >> > > 249 if (testFailed) { >> > > 250 >> output.reportDiagnosticSummary(); >> > > 251 if >> (output.getStderr().contains("Port already in >> > > use")) { >> > > 252 // Need to retry >> > > 253 return true; >> > > 254 } >> > > 255 } >> > > >> > > The test can still pass after this happens, right? >> And I think there are >> > > other "Test FAILURE" error message that can appear >> just before this. >> > > Perhaps the code above should add a println that >> indicates that there >> > > will be a retry attempt since the failure was due >> to the port being in use. >> > > >> > > Otherwise looks good. >> > > >> > > thanks, >> > > >> > > Chris >> > > >> > > On 7/17/19 1:30 PM, Alex Menkov wrote: >> > > > Hi Daniil, >> > > > >> > > > The fix looks good in general. >> > > > Couple cosmetic notes (no new webrev required): >> > > > >> > > > 162 needRetry = runTest(); >> > > > 163 } >> > > > 164 while (needRetry && (attempts++ >> < MAX_RETRY_ATTEMTS)); >> > > > Please move "while" to the prev line: >> > > > 163 } while (needRetry && >> (attempts++ < MAX_RETRY_ATTEMTS)); >> > > > >> > > > >> > > > 242 System.out.println("Test >> FAILURE on" + name + >> > > > " reason: The expected line \"" + READY_MSG >> > > > 243 + "\" is not >> present in the process >> > > > output"); >> > > > Please add space: "Test FAILURE on " + name >> > > > >> > > > --alex >> > > > >> > > > On 07/17/2019 12:46, Daniil Titov wrote: >> > > >> Hi Chris, >> > > >> >> > > >>> It's a little unclear to me why you moved >> from ProcessThread to >> > > >>> TestProcessThread + Process. An explanation >> of that would make it >> > > >>> easier >> > > >>> to understand many of the changes. >> > > >> >> > > >> There are two reasons for that: >> > > >> 1) For every network interface the test starts >> a separate thread >> > > >> that runs the test for this interface. We want >> that if the test fails >> > > >> due to the bind error the thread not to >> exit but try to repeat >> > > >> the test several times. >> jdk.test.lib.thread.ProcessThread doesn't >> > > >> allow this. >> > > >> 2) To filter out the cases when the test fails >> due to the bind error >> > > >> we need to parse the process output. >> jdk.test.lib.thread.ProcessThread >> > > >> registers its own pumps for stdin and sdtout >> (by calling >> > > >> ProcessTools.startProcess()) that consume all >> output of the process >> > > >> and prevent >> > > >> the output analyzer from collecting this output. >> > > >> Thanks! >> > > >> --Daniil >> > > >> >> > > >> ?On 7/17/19, 12:11 PM, "Chris Plummer" >> wrote: >> > > >> >> > > >> Hi Daniil, >> > > >> It's a little unclear to me why you >> moved from >> > > >> ProcessThread to >> > > >> TestProcessThread + Process. An explanation >> of that would make >> > > >> it easier >> > > >> to understand many of the changes. >> > > >> thanks, >> > > >> Chris >> > > >> On 7/11/19 10:16 AM, Daniil Titov wrote: >> > > >> > Please review the change that fixes an >> intermittent failure of >> > > >> >> sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java >> > > >> > test due to ports collision. The tests >> finds all network >> > > >> interfaces and for every interface starts a >> separate process that tests >> > > >> > the connection to JMX agent server for a >> specific >> > > >> ports/interface combination. >> > > >> > >> > > >> > The test was changed to retry in case of >> the failure. If the >> > > >> subprocess fails to bind and the number >> > > >> > of retry attempts doesn't exceed the >> limit a new pair of >> > > >> random ports is selected and the test is run again. >> > > >> > >> > > >> > Webrev: >> http://cr.openjdk.java.net/~dtitov/8221303/webrev.01/ >> > > >> > Bug: >> https://bugs.openjdk.java.net/browse/JDK-8221303 >> > > >> > >> > > >> > Thanks! >> > > >> > --Daniil >> > > >> > >> > > >> > >> > > >> >> > > >> >> > > >> > > >> > > >> > > >> > >> > >> > >> > >> > >> >> > > From daniil.x.titov at oracle.com Wed Jul 24 17:21:55 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Wed, 24 Jul 2019 10:21:55 -0700 Subject: jmx-dev RFR: 8185005: Improve performance of ThreadMXBean.getThreadInfo(long ids[], int maxDepth) In-Reply-To: References: <4C4212D0-BFFF-4C85-ACC6-05200F220C3F@oracle.com> <2d6dede1-aa79-99ce-a823-773fa2e19827@oracle.com> <6E7B043A-4647-4931-977C-1854CA7EBEC1@oracle.com> Message-ID: <76BCC96D-DB5D-409A-95D5-3A64B893832D@oracle.com> Hi David, Daniel, and Serguei, Please review the new version of the fix, that makes the thread table initialization on demand and moves it inside ThreadsList::find_JavaThread_from_java_tid(). At the creation time the thread table is initialized with the threads from the current thread list. We don't want to hold Threads_lock inside find_JavaThread_from_java_tid(), thus new threads still could be created while the thread table is being initialized . Such threads will be found by the linear search and added to the thread table later, in ThreadsList::find_JavaThread_from_java_tid(). The change also includes additional optimization for some callers of find_JavaThread_from_java_tid() as Daniel suggested. That is correct that ResolvedMethodTable was used as a blueprint for the thread table, however, I tried to strip it of the all functionality that is not required in the thread table case. We need to have the thread table resizable and allow it to grow as the number of threads increases to avoid reserving excessive memory a-priori or deteriorating lookup times. The ServiceThread is responsible for growing the thread table when required. There is no ConcurrentHashTable available in Java 8 and for backporting this fix to Java 8 another implementation of the hash table, probably originally suggested in the patch attached to the JBS issue, should be used. It will make the backporting more complicated, however, adding a new Implementation of the hash table in Java 14 while it already has ConcurrentHashTable doesn't seem reasonable for me. Webrev: http://cr.openjdk.java.net/~dtitov/8185005/webrev.03 Bug: https://bugs.openjdk.java.net/browse/JDK-8185005 Thanks! --Daniil ?On 7/8/19, 3:24 PM, "Daniel D. Daugherty" wrote: On 6/29/19 12:06 PM, Daniil Titov wrote: > Hi Serguei and David, > > Serguei is right, ThreadTable::find_thread(java_tid) cannot return a JavaThread with an unmatched java_tid. > > Please find a new version of the fix that includes the changes Serguei suggested. > > Regarding the concern about the maintaining the thread table when it may never even be queried, one of > the options could be to add ThreadTable ::isEnabled flag, set it to "false" by default, and wrap the calls to the thread table > in ThreadsSMRSupport add_thread() and remove_thread() methods to check this flag. > > When ThreadsList::find_JavaThread_from_java_tid() is called for the first time it could check if ThreadTable ::isEnabled > Is on and if not then set it on and populate the thread table with all existing threads from the thread list. I have the same concerns as David H. about this new ThreadTable. ThreadsList::find_JavaThread_from_java_tid() is only called from code in src/hotspot/share/services/management.cpp so I think that table needs to enabled and populated only if it is going to be used. I've taken a look at the webrev below and I see that David has followed up with additional comments. Before I do a crawl through code review for this, I would like to see the ThreadTable stuff made optional and David's other comments addressed. Another possible optimization is for callers of find_JavaThread_from_java_tid() to save the calling thread's tid value before they loop and if the current tid == saved_tid then use the current JavaThread* instead of calling find_JavaThread_from_java_tid() to get the JavaThread*. Dan > > Webrev: https://cr.openjdk.java.net/~dtitov/8185005/webrev.02/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8185005 > > Thanks! > --Daniil > > From: > Organization: Oracle Corporation > Date: Friday, June 28, 2019 at 7:56 PM > To: Daniil Titov , OpenJDK Serviceability , "hotspot-runtime-dev at openjdk.java.net" , "jmx-dev at openjdk.java.net" > Subject: Re: RFR: 8185005: Improve performance of ThreadMXBean.getThreadInfo(long ids[], int maxDepth) > > Hi Daniil, > > I have several quick comments. > > The indent in the hotspot c/c++ files has to be 2, not 4. > > https://cr.openjdk.java.net/~dtitov/8185005/webrev.01/src/hotspot/share/runtime/threadSMR.cpp.frames.html > 614 JavaThread* ThreadsList::find_JavaThread_from_java_tid(jlong java_tid) const { > 615 JavaThread* java_thread = ThreadTable::find_thread(java_tid); > 616 if (java_thread == NULL && java_tid == PMIMORDIAL_JAVA_TID) { > 617 // ThreadsSMRSupport::add_thread() is not called for the primordial > 618 // thread. Thus, we find this thread with a linear search and add it > 619 // to the thread table. > 620 for (uint i = 0; i < length(); i++) { > 621 JavaThread* thread = thread_at(i); > 622 if (is_valid_java_thread(java_tid,thread)) { > 623 ThreadTable::add_thread(java_tid, thread); > 624 return thread; > 625 } > 626 } > 627 } else if (java_thread != NULL && is_valid_java_thread(java_tid, java_thread)) { > 628 return java_thread; > 629 } > 630 return NULL; > 631 } > 632 bool ThreadsList::is_valid_java_thread(jlong java_tid, JavaThread* java_thread) { > 633 oop tobj = java_thread->threadObj(); > 634 // Ignore the thread if it hasn't run yet, has exited > 635 // or is starting to exit. > 636 return (tobj != NULL && !java_thread->is_exiting() && > 637 java_tid == java_lang_Thread::thread_id(tobj)); > 638 } > > 615 JavaThread* java_thread = ThreadTable::find_thread(java_tid); > > I'd suggest to rename find_thread() to find_thread_by_tid(). > > A space is missed after the comma: > 622 if (is_valid_java_thread(java_tid,thread)) { > > An empty line is needed before L632. > > The name 'is_valid_java_thread' looks wrong (or confusing) to me. > Something like 'is_alive_java_thread_with_tid()' would be better. > It'd better to list parameters in the opposite order. > > The call to is_valid_java_thread() is confusing: > 627 } else if (java_thread != NULL && is_valid_java_thread(java_tid, java_thread)) { > > Why would the call ThreadTable::find_thread(java_tid) return a JavaThread with an unmatched java_tid? > > > Thanks, > Serguei > > On 6/28/19, 9:40 PM, "David Holmes" wrote: > > Hi Daniil, > > The definition and use of this hashtable (yet another hashtable > implementation!) will need careful examination. We have to be concerned > about the cost of maintaining it when it may never even be queried. You > would need to look at footprint cost and performance impact. > > Unfortunately I'm just about to board a plane and will be out for the > next few days. I will try to look at this asap next week, but we will > need a lot more data on it. > > Thanks, > David > > On 6/28/19 3:31 PM, Daniil Titov wrote: > Please review the change that improves performance of ThreadMXBean MXBean methods returning the > information for specific threads. The change introduces the thread table that uses ConcurrentHashTable > to store one-to-one the mapping between the thread ids and JavaThread objects and replaces the linear > search over the thread list in ThreadsList::find_JavaThread_from_java_tid(jlong tid) method with the lookup > in the thread table. > > Testing: Mach5 tier1,tier2 and tier3 tests successfully passed. > > Webrev: https://cr.openjdk.java.net/~dtitov/8185005/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8185005 > > Thanks! > > Best regards, > Daniil > > > > > > > From daniil.x.titov at oracle.com Wed Jul 24 17:34:22 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Wed, 24 Jul 2019 10:34:22 -0700 Subject: jmx-dev RFR: 8170299: Debugger does not stop inside the low memory notifications code In-Reply-To: <60639d41-735a-00d3-c9db-1955f581b89a@oracle.com> References: <75B5F778-DC49-494B-AC12-270F301677CA@oracle.com> <60639d41-735a-00d3-c9db-1955f581b89a@oracle.com> Message-ID: Hi David, Hope you had a great vacation! Please find below the latest version of the change . The only difference from the version 01 is the corrected ordering of include statements as Serguei suggested. 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, 11:47 PM, "David Holmes" wrote: Hi Daniil, On 4/07/2019 1:04 pm, Daniil Titov wrote: > Please review the change the fixes the problem with the debugger not stopping in the low memory notification code. > > The problem here is that the ServiceThread that calls these MXBean listeners is hidden from the external view that prevents the debugger from stopping in it. > > The fix introduces new NotificationThread that is visible to the external view and offloads the ServiceThread from sending low memory and other notifications that could result in Java calls ( GC and diagnostic commands notifications) by moving these activities in this new NotificationThread. There is a long and unfortunate history with this bug. The original incarnation of this fix was introducing a new thread at the Java library level, and I had some concerns about that: http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-December/022612.html That effort was resurrected at: http://mail.openjdk.java.net/pipermail/serviceability-dev/2018-July/024466.html and http://mail.openjdk.java.net/pipermail/serviceability-dev/2018-August/024849.html but was left somewhat in limbo. There was a lot of doubt about the right way to fix this bug and whether introducing a new thread was too disruptive. But introducing a new thread in the VM also has the same set of concerns! This needs consideration by the runtime team before going ahead. Introducing a new thread likes this needs to be examined in detail - particularly the synchronization interactions with other threads. It also introduces another monitor designated safepoint-never at a time when we are in the process of cleaning up monitors so that JavaThreads will only use safepoint-check-always monitors. Unfortunately I'm about to head out for two weeks vacation, and a number of other key runtime folk are also on vacation. but I'd ask that you hold off on this until we can look at it in more detail. Thanks, David ----- > Testing: Mach5 tier1,tier2 and tier3 tests succeeded. > > Webrev: https://cr.openjdk.java.net/~dtitov/8170299/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8170299 > > Thanks! > --Daniil > > From david.holmes at oracle.com Mon Jul 29 07:53:09 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 29 Jul 2019 17:53:09 +1000 Subject: jmx-dev RFR: 8185005: Improve performance of ThreadMXBean.getThreadInfo(long ids[], int maxDepth) In-Reply-To: <76BCC96D-DB5D-409A-95D5-3A64B893832D@oracle.com> References: <4C4212D0-BFFF-4C85-ACC6-05200F220C3F@oracle.com> <2d6dede1-aa79-99ce-a823-773fa2e19827@oracle.com> <6E7B043A-4647-4931-977C-1854CA7EBEC1@oracle.com> <76BCC96D-DB5D-409A-95D5-3A64B893832D@oracle.com> Message-ID: <7e0ba39e-e5b7-f56b-66ea-820a0a35ec2c@oracle.com> Hi Daniil, Overall I think this is a reasonable approach but I would still like to see some performance and footprint numbers, both to verify it fixes the problem reported, and that we are not getting penalized elsewhere. On 25/07/2019 3:21 am, Daniil Titov wrote: > Hi David, Daniel, and Serguei, > > Please review the new version of the fix, that makes the thread table initialization on demand and > moves it inside ThreadsList::find_JavaThread_from_java_tid(). At the creation time the thread table > is initialized with the threads from the current thread list. We don't want to hold Threads_lock > inside find_JavaThread_from_java_tid(), thus new threads still could be created while the thread > table is being initialized . Such threads will be found by the linear search and added to the thread table > later, in ThreadsList::find_JavaThread_from_java_tid(). The initialization allows the created but unpopulated, or partially populated, table to be seen by other threads - is that your intention? It seems it should be okay as the other threads will then race with the initializing thread to add specific entries, and this is a concurrent map so that should be functionally correct. But if so then I think you can also reduce the scope of the ThreadTableCreate_lock so that it covers creation of the table only, not the initial population of the table. I like the approach of only initializing the table when needed and using that to control when the add/remove-thread code needs to update the table. But I would still want to see what impact this has on thread startup cost, both with and without the table being initialized. > The change also includes additional optimization for some callers of find_JavaThread_from_java_tid() > as Daniel suggested. Not sure it's best to combine these, but if they are limited to the changes in management.cpp only then that may be okay. It helps to be able to focus on the table related changes without being distracted by other optimizations. > That is correct that ResolvedMethodTable was used as a blueprint for the thread table, however, I tried > to strip it of the all functionality that is not required in the thread table case. The revised version seems better in that regard. But I still have a concern, see below. > We need to have the thread table resizable and allow it to grow as the number of threads increases to avoid > reserving excessive memory a-priori or deteriorating lookup times. The ServiceThread is responsible for > growing the thread table when required. Yes but why? Why can't this table be grown on demand by the thread that is doing the addition? For other tables we may have to delegate to the service thread because the current thread cannot perform the action, or it doesn't want to perform it at the time the need for the resize is detected (e.g. its detected at a safepoint and you want the resize to happen later outside the safepoint). It's not apparent to me that such restrictions apply here. > There is no ConcurrentHashTable available in Java 8 and for backporting this fix to Java 8 another implementation > of the hash table, probably originally suggested in the patch attached to the JBS issue, should be used. It will make > the backporting more complicated, however, adding a new Implementation of the hash table in Java 14 while it > already has ConcurrentHashTable doesn't seem reasonable for me. Ok. > Webrev: http://cr.openjdk.java.net/~dtitov/8185005/webrev.03 Some specific code comments: src/hotspot/share/runtime/mutexLocker.cpp + def(ThreadTableCreate_lock , PaddedMutex , special, false, Monitor::_safepoint_check_never); I think this needs to be a _safepoint_check_always lock. The table will be created by regular JavaThreads and they should (nearly) always be checking for safepoints if they are going to block acquiring the lock. And it isn't at all obvious that the thread doing the creation can't go to a safepoint whilst this lock is held. --- src/hotspot/share/runtime/threadSMR.cpp Nit: 618 JavaThread* thread = thread_at(i); you could reuse the new java_thread local you introduced at line 613 and just rename that "new" variable to "thread" so you don't have to change all other uses. 628 } else if (java_thread != NULL && ... You don't need to check != NULL here as you only get here when java_thread is not NULL. 755 jlong tid = SharedRuntime::get_java_tid(thread); 926 jlong tid = SharedRuntime::get_java_tid(thread); I think it cleaner/better to just use jlong tid = java_lang_Thread::thread_id(thread->threadObj()); as we know thread is not NULL, it is a JavaThread and it has to have a non-null threadObj. --- src/hotspot/share/services/management.cpp 1323 if (THREAD->is_Java_thread()) { 1324 JavaThread* current_thread = (JavaThread*)THREAD; These calls can only be made on a JavaThread so this be simplified to remove the is_Java_thread() call. Similarly in other places. --- src/hotspot/share/services/threadTable.cpp 55 class ThreadTableEntry : public CHeapObj { 56 private: 57 jlong _tid; I believe hotspot style is to not indent the access modifiers in C++ class declarations, so the above would just be: 55 class ThreadTableEntry : public CHeapObj { 56 private: 57 jlong _tid; etc. 60 ThreadTableEntry(jlong tid, JavaThread* java_thread) : 61 _tid(tid),_java_thread(java_thread) {} line 61 should be indented as it continues line 60. 67 class ThreadTableConfig : public AllStatic { ... 71 static uintx get_hash(Value const& value, bool* is_dead) { The is_dead parameter still bothers me here. I can't make enough sense out of the template code in ConcurrentHashtable to see why we have to have it, but I'm concerned that its very existence means we perhaps should not be trying to extend CHT in this context. ?? 115 size_t start_size_log = size_log > DefaultThreadTableSizeLog 116 ? size_log : DefaultThreadTableSizeLog; line 116 should be indented, though in this case I think a better layout would be: 115 size_t start_size_log = 116 size_log > DefaultThreadTableSizeLog ? size_log : DefaultThreadTableSizeLog; 131 double ThreadTable::get_load_factor() { 132 return (double)_items_count/_current_size; 133 } Not sure that is doing what you want/expect. It will perform integer division and then cast that whole integer to a double. If you want double arithmetic you need: return ((double)_items_count)/_current_size; 180 jlong _tid; 181 uintx _hash; Nit: no need for all those spaces before the variable name. 183 ThreadTableLookup(jlong tid) 184 : _tid(tid), _hash(primitive_hash(tid)) {} line 184 should be indented. 201 ThreadGet():_return(NULL) {} Nit: need space after : 211 assert(_is_initialized, "Thread table is not initialized"); 212 _has_work = false; line 211 is indented one space too far. 229 ThreadTableEntry* entry = new ThreadTableEntry(tid,java_thread); Nit: need space after , 252 return _local_table->remove(thread,lookup); Nit: need space after , Thanks, David ------ > Bug: https://bugs.openjdk.java.net/browse/JDK-8185005 > > Thanks! > --Daniil > > > ?On 7/8/19, 3:24 PM, "Daniel D. Daugherty" wrote: > > On 6/29/19 12:06 PM, Daniil Titov wrote: > > Hi Serguei and David, > > > > Serguei is right, ThreadTable::find_thread(java_tid) cannot return a JavaThread with an unmatched java_tid. > > > > Please find a new version of the fix that includes the changes Serguei suggested. > > > > Regarding the concern about the maintaining the thread table when it may never even be queried, one of > > the options could be to add ThreadTable ::isEnabled flag, set it to "false" by default, and wrap the calls to the thread table > > in ThreadsSMRSupport add_thread() and remove_thread() methods to check this flag. > > > > When ThreadsList::find_JavaThread_from_java_tid() is called for the first time it could check if ThreadTable ::isEnabled > > Is on and if not then set it on and populate the thread table with all existing threads from the thread list. > > I have the same concerns as David H. about this new ThreadTable. > ThreadsList::find_JavaThread_from_java_tid() is only called from code > in src/hotspot/share/services/management.cpp so I think that table > needs to enabled and populated only if it is going to be used. > > I've taken a look at the webrev below and I see that David has > followed up with additional comments. Before I do a crawl through > code review for this, I would like to see the ThreadTable stuff > made optional and David's other comments addressed. > > Another possible optimization is for callers of > find_JavaThread_from_java_tid() to save the calling thread's > tid value before they loop and if the current tid == saved_tid > then use the current JavaThread* instead of calling > find_JavaThread_from_java_tid() to get the JavaThread*. > > Dan > > > > > Webrev: https://cr.openjdk.java.net/~dtitov/8185005/webrev.02/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8185005 > > > > Thanks! > > --Daniil > > > > From: > > Organization: Oracle Corporation > > Date: Friday, June 28, 2019 at 7:56 PM > > To: Daniil Titov , OpenJDK Serviceability , "hotspot-runtime-dev at openjdk.java.net" , "jmx-dev at openjdk.java.net" > > Subject: Re: RFR: 8185005: Improve performance of ThreadMXBean.getThreadInfo(long ids[], int maxDepth) > > > > Hi Daniil, > > > > I have several quick comments. > > > > The indent in the hotspot c/c++ files has to be 2, not 4. > > > > https://cr.openjdk.java.net/~dtitov/8185005/webrev.01/src/hotspot/share/runtime/threadSMR.cpp.frames.html > > 614 JavaThread* ThreadsList::find_JavaThread_from_java_tid(jlong java_tid) const { > > 615 JavaThread* java_thread = ThreadTable::find_thread(java_tid); > > 616 if (java_thread == NULL && java_tid == PMIMORDIAL_JAVA_TID) { > > 617 // ThreadsSMRSupport::add_thread() is not called for the primordial > > 618 // thread. Thus, we find this thread with a linear search and add it > > 619 // to the thread table. > > 620 for (uint i = 0; i < length(); i++) { > > 621 JavaThread* thread = thread_at(i); > > 622 if (is_valid_java_thread(java_tid,thread)) { > > 623 ThreadTable::add_thread(java_tid, thread); > > 624 return thread; > > 625 } > > 626 } > > 627 } else if (java_thread != NULL && is_valid_java_thread(java_tid, java_thread)) { > > 628 return java_thread; > > 629 } > > 630 return NULL; > > 631 } > > 632 bool ThreadsList::is_valid_java_thread(jlong java_tid, JavaThread* java_thread) { > > 633 oop tobj = java_thread->threadObj(); > > 634 // Ignore the thread if it hasn't run yet, has exited > > 635 // or is starting to exit. > > 636 return (tobj != NULL && !java_thread->is_exiting() && > > 637 java_tid == java_lang_Thread::thread_id(tobj)); > > 638 } > > > > 615 JavaThread* java_thread = ThreadTable::find_thread(java_tid); > > > > I'd suggest to rename find_thread() to find_thread_by_tid(). > > > > A space is missed after the comma: > > 622 if (is_valid_java_thread(java_tid,thread)) { > > > > An empty line is needed before L632. > > > > The name 'is_valid_java_thread' looks wrong (or confusing) to me. > > Something like 'is_alive_java_thread_with_tid()' would be better. > > It'd better to list parameters in the opposite order. > > > > The call to is_valid_java_thread() is confusing: > > 627 } else if (java_thread != NULL && is_valid_java_thread(java_tid, java_thread)) { > > > > Why would the call ThreadTable::find_thread(java_tid) return a JavaThread with an unmatched java_tid? > > > > > > Thanks, > > Serguei > > > > On 6/28/19, 9:40 PM, "David Holmes" wrote: > > > > Hi Daniil, > > > > The definition and use of this hashtable (yet another hashtable > > implementation!) will need careful examination. We have to be concerned > > about the cost of maintaining it when it may never even be queried. You > > would need to look at footprint cost and performance impact. > > > > Unfortunately I'm just about to board a plane and will be out for the > > next few days. I will try to look at this asap next week, but we will > > need a lot more data on it. > > > > Thanks, > > David > > > > On 6/28/19 3:31 PM, Daniil Titov wrote: > > Please review the change that improves performance of ThreadMXBean MXBean methods returning the > > information for specific threads. The change introduces the thread table that uses ConcurrentHashTable > > to store one-to-one the mapping between the thread ids and JavaThread objects and replaces the linear > > search over the thread list in ThreadsList::find_JavaThread_from_java_tid(jlong tid) method with the lookup > > in the thread table. > > > > Testing: Mach5 tier1,tier2 and tier3 tests successfully passed. > > > > Webrev: https://cr.openjdk.java.net/~dtitov/8185005/webrev.01/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8185005 > > > > Thanks! > > > > Best regards, > > Daniil > > > > > > > > > > > > > > > > > > From serguei.spitsyn at oracle.com Mon Jul 29 09:12:01 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 29 Jul 2019 02:12:01 -0700 Subject: jmx-dev RFR: 8185005: Improve performance of ThreadMXBean.getThreadInfo(long ids[], int maxDepth) In-Reply-To: <76BCC96D-DB5D-409A-95D5-3A64B893832D@oracle.com> References: <4C4212D0-BFFF-4C85-ACC6-05200F220C3F@oracle.com> <2d6dede1-aa79-99ce-a823-773fa2e19827@oracle.com> <6E7B043A-4647-4931-977C-1854CA7EBEC1@oracle.com> <76BCC96D-DB5D-409A-95D5-3A64B893832D@oracle.com> Message-ID: <65e52a11-21b3-58d2-a707-c7ecdc8bcff7@oracle.com> An HTML attachment was scrubbed... URL: From daniil.x.titov at oracle.com Mon Jul 29 15:37:25 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Mon, 29 Jul 2019 08:37:25 -0700 Subject: jmx-dev 8185005: Improve performance of ThreadMXBean.getThreadInfo(long ids[], int maxDepth) In-Reply-To: <65e52a11-21b3-58d2-a707-c7ecdc8bcff7@oracle.com> References: <4C4212D0-BFFF-4C85-ACC6-05200F220C3F@oracle.com> <2d6dede1-aa79-99ce-a823-773fa2e19827@oracle.com> <6E7B043A-4647-4931-977C-1854CA7EBEC1@oracle.com> <76BCC96D-DB5D-409A-95D5-3A64B893832D@oracle.com> <65e52a11-21b3-58d2-a707-c7ecdc8bcff7@oracle.com> Message-ID: Hi Serguei, Thank you for catching this! Regarding the testing, at this stage, I run all tier1- tier3 tests . I will check why this specific case was ?not included in the tests and will add it if required. Thanks, Daniil From: "serguei.spitsyn at oracle.com" Date: Monday, July 29, 2019 at 2:12 AM To: Daniil Titov , , OpenJDK Serviceability , "hotspot-runtime-dev at openjdk.java.net" , "jmx-dev at openjdk.java.net" , David Holmes Subject: Re: RFR: 8185005: Improve performance of ThreadMXBean.getThreadInfo(long ids[], int maxDepth) 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 ?????? } else { ???????? // reset contention statistics for a given thread +??????? JavaThread* java_thread = NULL; +??????? if (THREAD->is_Java_thread()) { +????????? JavaThread* current_thread = (JavaThread*)THREAD; +????????? if (tid == java_lang_Thread::thread_id(current_thread->threadObj())) { +??????????? java_thread = current_thread; +????????? } +??????? } +??????? if (java_thread == NULL) { ???????? JavaThread* java_thread = jtiwh.list()->find_JavaThread_from_java_tid(tid); +??????? } ???????? if (java_thread == NULL) { ?????????? return false; ???????? } Now, the definition of java_thread below: +??????? if (java_thread == NULL) { ?????????? JavaThread* java_thread = jtiwh.list()->find_JavaThread_from_java_tid(tid); +??????? } becomes completely useless because the block of its definition is ended right away. Here, overriding the local variable 'java_thread' does not look as a good idea. Then how was it really tested? Thanks, Serguei On 7/24/19 10:21, Daniil Titov wrote: Hi David, Daniel, and Serguei, Please review the new version of the fix, that makes the thread table initialization on demand and moves it inside ThreadsList::find_JavaThread_from_java_tid(). At the creation time the thread table is initialized with the threads from the current thread list. We don't want to hold Threads_lock inside find_JavaThread_from_java_tid(),? thus new threads still could be created? while the thread table is being initialized . Such threads will be found by the linear search and added to the thread table later, in ThreadsList::find_JavaThread_from_java_tid(). The change also includes additional optimization for some callers of find_JavaThread_from_java_tid() as Daniel suggested. That is correct that ResolvedMethodTable was used as a blueprint for the thread table, however, I tried to strip it of the all functionality that is not required in the thread table case. We need to have the thread table resizable and allow it to grow as the number of threads increases to avoid? reserving excessive memory a-priori or deteriorating lookup times. The ServiceThread is responsible for growing the thread table when required. There is no ConcurrentHashTable available in Java 8 and for backporting this fix to Java 8 another implementation of the hash table, probably originally suggested in the patch attached to the JBS issue, should be used.? It will make the backporting more complicated,? however, adding a new Implementation of the hash table in Java 14 while it already has ConcurrentHashTable doesn't seem? reasonable for me. Webrev: http://cr.openjdk.java.net/~dtitov/8185005/webrev.03 Bug: https://bugs.openjdk.java.net/browse/JDK-8185005 Thanks! --Daniil ?On 7/8/19, 3:24 PM, "Daniel D. Daugherty" wrote: ??? On 6/29/19 12:06 PM, Daniil Titov wrote: ??? > Hi Serguei and David, ??? > ??? > Serguei is right, ThreadTable::find_thread(java_tid) cannot? return a JavaThread with an unmatched java_tid. ??? > ??? > Please find a new version of the fix that includes the changes Serguei suggested. ??? > ??? > Regarding the concern about the maintaining the thread table when it may never even be queried, one of ??? > the options could be to add ThreadTable ::isEnabled flag, set it to "false" by default, and wrap the calls to the thread table ??? > in ThreadsSMRSupport add_thread() and remove_thread() methods to check this flag. ??? > ??? > When ThreadsList::find_JavaThread_from_java_tid() is called for the first time it could check if ThreadTable ::isEnabled ??? > Is on and if not then set it on and populate the thread table with all existing threads from the thread list. ??? ????I have the same concerns as David H. about this new ThreadTable. ??? ThreadsList::find_JavaThread_from_java_tid() is only called from code ??? in src/hotspot/share/services/management.cpp so I think that table ??? needs to enabled and populated only if it is going to be used. ??? ????I've taken a look at the webrev below and I see that David has ??? followed up with additional comments. Before I do a crawl through ??? code review for this, I would like to see the ThreadTable stuff ??? made optional and David's other comments addressed. ??? ????Another possible optimization is for callers of ??? find_JavaThread_from_java_tid() to save the calling thread's ??? tid value before they loop and if the current tid == saved_tid ??? then use the current JavaThread* instead of calling ??? find_JavaThread_from_java_tid() to get the JavaThread*. ??? ????Dan ??? ????> ??? > Webrev: https://cr.openjdk.java.net/~dtitov/8185005/webrev.02/ ??? > Bug: https://bugs.openjdk.java.net/browse/JDK-8185005 ??? > ??? > Thanks! ??? > --Daniil ??? > ??? > From: ??? > Organization: Oracle Corporation ??? > Date: Friday, June 28, 2019 at 7:56 PM ??? > To: Daniil Titov , OpenJDK Serviceability , "hotspot-runtime-dev at openjdk.java.net" , "jmx-dev at openjdk.java.net" ??? > Subject: Re: RFR: 8185005: Improve performance of ThreadMXBean.getThreadInfo(long ids[], int maxDepth) ??? > ??? > Hi Daniil, ??? > ??? > I have several quick comments. ??? > ??? > The indent in the hotspot c/c++ files has to be 2, not 4. ??? > ??? > https://cr.openjdk.java.net/~dtitov/8185005/webrev.01/src/hotspot/share/runtime/threadSMR.cpp.frames.html ??? > 614 JavaThread* ThreadsList::find_JavaThread_from_java_tid(jlong java_tid) const { ??? >?? 615???? JavaThread* java_thread = ThreadTable::find_thread(java_tid); ??? >?? 616???? if (java_thread == NULL && java_tid == PMIMORDIAL_JAVA_TID) { ??? >?? 617???????? // ThreadsSMRSupport::add_thread() is not called for the primordial ??? >?? 618???????? // thread. Thus, we find this thread with a linear search and add it ??? >?? 619???????? // to the thread table. ??? >?? 620???????? for (uint i = 0; i < length(); i++) { ??? >?? 621???????????? JavaThread* thread = thread_at(i); ??? >?? 622???????????? if (is_valid_java_thread(java_tid,thread)) { ??? >?? 623???????????????? ThreadTable::add_thread(java_tid, thread); ??? >?? 624???????????????? return thread; ??? >?? 625???????????? } ??? >?? 626???????? } ??? >?? 627???? } else if (java_thread != NULL && is_valid_java_thread(java_tid, java_thread)) { ??? >?? 628???????? return java_thread; ??? >?? 629???? } ??? >?? 630???? return NULL; ??? >?? 631 } ??? >?? 632 bool ThreadsList::is_valid_java_thread(jlong java_tid, JavaThread* java_thread) { ??? >?? 633???? oop tobj = java_thread->threadObj(); ??? >?? 634???? // Ignore the thread if it hasn't run yet, has exited ??? >?? 635???? // or is starting to exit. ??? >?? 636???? return (tobj != NULL && !java_thread->is_exiting() && ??? >?? 637???????????? java_tid == java_lang_Thread::thread_id(tobj)); ??? >?? 638 } ??? > ??? >?? 615?? ??JavaThread* java_thread = ThreadTable::find_thread(java_tid); ??? > ??? >??? I'd suggest to rename find_thread() to find_thread_by_tid(). ??? > ??? > A space is missed after the comma: ??? >??? 622 if (is_valid_java_thread(java_tid,thread)) { ??? > ??? > An empty line is needed before L632. ??? > ??? > The name 'is_valid_java_thread' looks wrong (or confusing) to me. ??? > Something like 'is_alive_java_thread_with_tid()' would be better. ??? > It'd better to list parameters in the opposite order. ??? > ??? > The call to is_valid_java_thread() is confusing: ??? >???? 627 } else if (java_thread != NULL && is_valid_java_thread(java_tid, java_thread)) { ??? > ??? > Why would the call ThreadTable::find_thread(java_tid) return a JavaThread with an unmatched java_tid? ??? > ??? >?? ????> Thanks, ??? > Serguei ??? > ??? > On 6/28/19, 9:40 PM, "David Holmes" wrote: ??? > ??? >????? Hi Daniil, ??? >????? ????>????? The definition and use of this hashtable (yet another hashtable ??? >????? implementation!) will need careful examination. We have to be concerned ??? >????? about the cost of maintaining it when it may never even be queried. You ??? >????? would need to look at footprint cost and performance impact. ??? >????? ????>????? Unfortunately I'm just about to board a plane and will be out for the ??? >????? next few days. I will try to look at this asap next week, but we will ? ??>????? need a lot more data on it. ??? >????? ????>????? Thanks, ??? >????? David ??? > ??? > On 6/28/19 3:31 PM, Daniil Titov wrote: ??? > Please review the change that improves performance of ThreadMXBean MXBean methods returning the ??? > information for specific threads. The change introduces the thread table that uses ConcurrentHashTable ??? > to store one-to-one the mapping between the thread ids and JavaThread objects and replaces the linear ??? > search over the thread list in ThreadsList::find_JavaThread_from_java_tid(jlong tid) method with the lookup ??? > in the thread table. ??? > ??? > Testing: Mach5 tier1,tier2 and tier3 tests successfully passed. ??? > ??? > Webrev: https://cr.openjdk.java.net/~dtitov/8185005/webrev.01/ ??? > Bug: https://bugs.openjdk.java.net/browse/JDK-8185005 ??? > ??? > Thanks! ??? > ??? > Best regards, ??? > Daniil ??? > ??? > ??? > ??? > ??? > ??? > ??? > ??? ???? -------------- next part -------------- An HTML attachment was scrubbed... URL: