> On Jul 14, 2016, at 8:55 AM, David Holmes <david.hol...@oracle.com> wrote: > > On 13/07/2016 9:06 PM, Mandy Chung wrote: >> >>> On Jul 13, 2016, at 6:56 PM, Amit Sapre <amit.sa...@oracle.com> wrote: >>> >>> Hello, >>> Please review the fix >>> >>> Bug ID : https://bugs.openjdk.java.net/browse/JDK-8151099 >>> Webrev : http://cr.openjdk.java.net/~hb/sponsorship/8151099/webrev.00/ >> >> Looks okay. >> >> You could rename the method to load_and_initialize_klass_or_null to follow >> the existing naming convention. > > +1 on that "softload" is not suitable. > > My concern is that the code that calls > Management::com_sun_management_internal_GarbageCollectorExtImpl_klass > does not seem to handle getting NULL correctly: > > ./share/vm/services/memoryManager.cpp > ./share/vm/services/gcNotifier.cpp
Thanks for pointing this out. We will need to make sure that when jdk.management is present, it will create com.sun.management.internal.GarbageCollectorExtImpl as the GC memory manager objects for jmm_GetMemoryManagers. That implements com.sun.management.GarbageCollectorMXBean. When jdk.management is not present, it should return sun.management.GarbageCollectorImpl instead that implements java.lang.management.GarbageCollectorMXBean. gcNotifier implements both com.sun.management.GcInfo as well as java.lang.management.MemoryPoolMXBean notification. More surgery might need to be done to make sure the implementation handles properly when jdk.management is present and absent. Mandy
