[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    Re: RFR: 8170299: Debugger does not stop inside the low memory notifications code
From:       Daniil Titov <daniil.x.titov () oracle ! com>
Date:       2019-07-24 17:34:22
Message-ID: E2BFE392-EF77-4072-9D7C-65C088D4F007 () oracle ! com
[Download RAW message or body]

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" <david.holmes@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
    > 
    > 
    


[prev in list] [next in list] [prev in thread] [next in thread]