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" <david.hol...@oracle.com> 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 > >
