Hi Coleen,
It looks like a nice simplification and cleanup. Thank you for taking care about it! Could you, please, explain a little bit the changes in the getClassLoaderClasses? If I understand it correctly, the iteration ClassLoaderDataGraph::dictionary_all_entries_do(&JvmtiGetLoadedClassesClosure::increment_with_loader) is replaced with the data->dictionary()->all_entries_do(&closure), or for boot class loader, with ClassLoaderData::the_null_class_loader_data()->dictionary()->all_entries_do(&closure). It is not clear (I have just some guesses) if it would do the same and why does it support concurrent class unloading for ZGC. Is it worth to add a minimal comment explaining this? Thanks, Serguei On 8/23/18 05:37, coleen.phillim...@oracle.com wrote: Summary: And also added function with KlassClosure to remove the hacks. |
- RFR 8209821: Make JVMTI GetClassLoaderClasses n... coleen . phillimore
- Re: RFR 8209821: Make JVMTI GetClassLoader... Lois Foltan
- Re: RFR 8209821: Make JVMTI GetClassLo... coleen . phillimore
- Re: RFR 8209821: Make JVMTI GetCla... Lois Foltan
- Re: RFR 8209821: Make JVMTI Ge... coleen . phillimore
- Re: RFR 8209821: Make JVMTI GetClassLoader... serguei.spit...@oracle.com
- Re: RFR 8209821: Make JVMTI GetClassLo... serguei.spit...@oracle.com
- Re: RFR 8209821: Make JVMTI GetClassLo... coleen . phillimore
- Re: RFR 8209821: Make JVMTI GetCla... serguei.spit...@oracle.com
- Re: RFR 8209821: Make JVMTI Ge... coleen . phillimore