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

List:       openjdk-serviceability-dev
Subject:    Re: RFR : JDK-8170299 - Debugger does not stop inside the low memory notifications code
From:       "Daniel D. Daugherty" <daniel.daugherty () oracle ! com>
Date:       2018-08-30 18:12:49
Message-ID: c0e08429-3d66-288a-89ca-4a105e65b557 () oracle ! com
[Download RAW message or body]

Adding hotspot-runtime-dev@... to this thread...

More below...


On 8/28/18 3:37 PM, mandy chung wrote:
>
>
> 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

More work is being moved from the VMThread to the ServiceThread. I don't
think making the ServiceThread visible (and thus suspend-able) is going
to be viable.

JDK-8206424 Use ConcurrentHashTable for ProtectionDomainTable
https://bugs.openjdk.java.net/browse/JDK-8206424

JDK-8206423 Use ConcurrentHashTable for ResolvedMethodTable
https://bugs.openjdk.java.net/browse/JDK-8206423

There may be more work in progress for off loading the VMThread...

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