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

[Daniel D. Daugherty]

Adding hotspot-runtime-dev at ... 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