Hi all,
why does JDT subscribe to JVM class unload events after attaching to a JVM to debug it? It subscribes with the following code:
org.eclipse.jdi.internal.VirtualMachineImpl.packetSendManager()
// TBD: This call should be moved to addKnownRefType() when it can
// be made specific
// for a reference type.
eventRequestManagerImpl().enableInternalClasUnloadEvent();
/**
* Creates ClassUnloadRequest for maintaining class information for within JDI.
* Needed to known when to flush the cache.
*/
public void enableInternalClasUnloadEvent(/* TBD: ReferenceTypeImpl refType*/) {
// Note that these requests are not stored in the set of outstanding requests because
// they must be invisible from outside.
ClassUnloadRequestImpl reqUnload = new ClassUnloadRequestImpl(virtualMachineImpl());
reqUnload.setGeneratedInside();
// TBD: It is now yet possible to only ask for unload events for
// classes that we know of due to a limitation in the J9 VM.
// reqUnload.addClassFilter(refType);
reqUnload.setSuspendPolicy(EventRequest.SUSPEND_NONE);
reqUnload.enable();
}
Unfortunately I'm not seeing which cache is being flushed (see Java doc above) from just the code above. I'll keep looking but if someone knows it would help speed-up the process a lot.
Background:
This has to do with the JVM keeping track of loaded classes, in order to notify the attached debugger about unloaded classes. We then observed that JDT does care about class unload events, notifications are requested as described above.
Best regards and thanks,
Simeon
