RFR : JDK-8170299 - Debugger does not stop inside the low memory notifications code

[mandy chung]

On 8/24/18 7:06 AM, Daniel Fuchs wrote:
> Hi Harsha,
>
> On 23/08/2018 17:35, Daniel Fuchs wrote:
>> So all in all - maybe this is worth fixing but better early
>> in the release than late. I also wonder whether such a behavior
>> change should deserve a release note (or a switch to revert
>> to the old behavior - though I do hope that isn't necessary).
>
> On second thought - it occurred to me that what you are proposing
> to do in the platform could very well be implemented in the
> client (listener) code instead.
>
> The workaround would be simple:
>
> -------------------------------
> package com.foo.monitoring;
>
> import javax.management.*;
>
> final class PlatformMXBeaNotificationListener implements
>       NotificationListener {
>
>     private final NotoificationListener delegate;
>
>     PlatformMXBeaNotificationListener(NotoificationListener delegate) {
>     this.delegate = delegate;
>     }
>
>     public void handleNotification(Notification notification,
>                                    Object handback) {
>          executor.execute(() ->
>                delegate.handleNotification(notification, handback));
>     }
>
>     private static final Executor executor
>           = Executors.newSingleTreadExecutor();
> }
> --------------------------------
>
> This way the threading would remain in control of the
> client application, and the debugger would be able to
> step in the delegate's handleNotification(...) method?
>
> Given the unquantifiable risk posed by changing the threading
> model in the platform, then maybe leaving the current
> implementation as is and documenting that workaround
> leaving it up to the client code to decide whether to use
> that or not, would be the better idea?
>

I agree that this is a behavioral change but I suspect this is not high 
compatibility risk
though (no data though).   I understand David's concern that this is to 
fix a debugger
issue and we should investigate other alternatives to minimize the 
compatibility risk.

The other approach David has proposed is to investigate if we can make 
the service thread
not hidden.   The threading model in the notification listener 
invocation remains unchanged.
In addition, the VM service thread also handles DCMD and JVM TI 
callbacks.  I don't know
if there are public API to register DCMD callback.  If so, it will 
enable debugging
user-defined DCMD callback for free then.  The notion of hidden VM 
JavaThread was added
to avoid a compiler thread and other system thread being suspended and 
resumed
(see JDK-4529296).   So we should be careful and look into past issues 
to make the
VM thread visible to debugger.  It may be a feasible solution.

In any case, it would be useful to clarify the spec w.r.t. the 
synchronization and threads
invoking the listeners and users should prepare the listeners may be 
invoked
asynchronously in parallel.

Mandy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20180828/1ee1ed26/attachment-0001.html>