Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jdt-dev] Why does JDT subscribe to JVM class unload events?

see commented out code in addCachedMirror(ReferenceTypeImpl). This also could explain the classes leak we observe if debugger is attached. 

Am 17. September 2019 20:13:00 MESZ schrieb Simeon Andreev <simeon.danailov.andreev@xxxxxxxxx>:
>Hi all,
>why does JDT subscribe to JVM class unload events after attaching to a
>to debug it? It subscribes with the following code:
>// TBD: This call should be moved to addKnownRefType() when it can
>// be made specific
>// for a reference type.
>* Creates ClassUnloadRequest for maintaining class information for
>* 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
>     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
>would help speed-up the process a lot.
>We recently observed that
>hinders performance in our product.
>This has to do with the JVM keeping track of loaded classes, in order
>notify the attached debugger about unloaded classes. We then observed
>JDT does care about class unload events, notifications are requested as
>described above.
>The code is present from the very first git commit:
>Best regards and thanks,

Kind regards,
Andrey Loskutov
Спасение утопающих - дело рук самих утопающих

Back to the top