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.spit...@oracle.com" <serguei.spit...@oracle.com> Date: Tuesday, July 9, 2019 at 1:37 AM To: Daniil Titov <daniil.x.ti...@oracle.com>, OpenJDK Serviceability <serviceability-dev@openjdk.java.net>, "hotspot-runtime-...@openjdk.java.net" <hotspot-runtime-...@openjdk.java.net>, "jmx-...@openjdk.java.net" <jmx-...@openjdk.java.net>, David Holmes <david.hol...@oracle.com> 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.spit...@oracle.com mailto:serguei.spit...@oracle.com Date: Monday, July 8, 2019 at 3:09 PM To: Daniil Titov mailto:daniil.x.ti...@oracle.com, OpenJDK Serviceability mailto:serviceability-dev@openjdk.java.net, mailto:hotspot-runtime-...@openjdk.java.net mailto:hotspot-runtime-...@openjdk.java.net, mailto:jmx-...@openjdk.java.net mailto:jmx-...@openjdk.java.net, David Holmes mailto:david.hol...@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.spit...@oracle.com mailto:serguei.spit...@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 > >
