On 7/13/17 2:45 AM, Shafi Ahmad wrote:
Hi,
Please review the code change for the fix of bug 'JDK-8169961: Memory leak
after debugging session'
Summary:
1. It seems that the thread created for
com.sun.tools.jdi.TargetVM.EventController is never stopped and keeps a hard
reference to the VirtualMachineImpl. This leads to VirtualMachineImpl leak
after debug session is finished. EventController is private class and member
field vm of type VirtualMachineImpl, holding the hard reference to the
VirtualMachineImpl. I am not seeing the usage of filed vm so we can remove it
safely.
2. Added eventController.release(); before 'Target VM interface thread exiting'
3. TargetVM gets an EventController which is a daemon thread, but don't see
the thread having a way of stopping so added code to exit as soon as TargetVM
thread stops listening.
jdk10 bug: https://bugs.openjdk.java.net/browse/JDK-8169961
webrev link: http://cr.openjdk.java.net/~shshahma/8169961/webrev.00/
src/jdk.jdi/share/classes/com/sun/tools/jdi/TargetVM.java
L330: VirtualMachineImpl vm;
L335: this.vm = vm;
This comment caught my eye:
> I am not seeing the usage of filed vm so we can remove it safely.
So you're deleting the 'vm' instance variable, but:
L363: JDWP.VirtualMachine.HoldEvents.process(vm);
L365: JDWP.VirtualMachine.ReleaseEvents.process(vm);
would use it if it was still there...
Where did the run() method find a 'vm' variable? I'm guessing
the one in the TargetVM outer class:
L46: private VirtualMachineImpl vm;
Okay so we don't have to pass (and save a copy of
VirtualMachineImpl).
So this constructor:
L333: EventController(VirtualMachineImpl vm) {
No longer uses the 'vm' parameter at all and you
can remove the parameter and update the caller.
Testing: run jprt and I provided the FBP and it works for them.
JPRT doesn't execute any JDI related tests. You need to run
the NSK JDI test suite and the com/sun/jdi tests in the JDK.
Dan
Regards,
Shafi
