RFR(M): JDK-8141070 vm/services/management.cpp should be resilient to missing 'jdk.management' module

Dmitry Samersoff dmitry.samersoff at oracle.com
Thu Jan 14 14:49:56 UTC 2016


Daniel,
> OK. What of the sun.* implementation classes in java.management?
> Should these be REQUIRED as well?

java.management module might be missing. It's the main goal to the fix -
provide a way to handle missing java.management module on VM level.

i.e.

if java.lang.management is missing, VM fails with NCDFE.

if java.management is missing, implementation of particular function can
do something to handle it.

-Dmitry


On 2016-01-14 16:00, Daniel Fuchs wrote:
> Hi Dmitry,
> 
> On 14/01/16 13:31, Dmitry Samersoff wrote:
>> Daniel,
>>
>>> What strategy did you use to decide whether
>>> to use OPTIONAL | REQUIRED?
>>> I'm not sure I understand the logic...
>>
>> Everything in java.lang.management should be REQUIRED, anything outside
>> of it - OPTIONAL.
>>
>> java_lang_management_MemoryUsage_klass should be required, it's just a
>> typeo.
> 
> OK. What of the sun.* implementation classes in java.management?
> Should these be REQUIRED as well?
> 
> best regards,
> 
> -- daniel
> 
> 
>>
>> -Dmitry
>>
>> On 2016-01-14 14:48, Daniel Fuchs wrote:
>>> Hi Dmitry,
>>>
>>> First an observation:
>>>
>>> - java.lang.management and sun.management packages are part of
>>>    the java.management module.
>>>
>>> - com.sun.management and com.sun.management.internal are part
>>>    of jdk.management
>>>
>>> What strategy did you use to decide whether to use OPTIONAL | REQUIRED?
>>> I'm not sure I understand the logic...
>>
>> Everything in java.lang.management should be required, anything outside
>> of it - optional.
>>
>>>
>>> For instance:
>>>
>>>    80   Klass* k =
>>> Management::com_sun_management_internal_GarbageCollectorExtImpl_klass(Management::OPTIONAL,
>>>
>>> CHECK_NH);
>>>
>>>    => class from jdk.management: OPTIONAL looks like the right choice.
>>>
>>>   103   Klass* mu_klass =
>>> Management::java_lang_management_MemoryUsage_klass(Management::OPTIONAL,
>>> CHECK_NH);
>>>
>>>    => class from java.management: should it be REQUIRED?
>>>       Or is it optional for some other reason (e.g. the feature/method
>>>       depends on jdk.management being present)?
>>>       Or is it optional to make room for the case when
>>> java.management is
>>>       not there?
>>>
>>> Is there some other underlying logic here?
>>>
>>> best regards,
>>>
>>> -- daniel
>>>
>>> On 13/01/16 19:45, Dmitry Samersoff wrote:
>>>> Everybody,
>>>>
>>>> Please, review the fix:
>>>>
>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8141070/webrev.01/
>>>>
>>>> The problem:
>>>>
>>>>     Code in management.cpp throw NoClassDefFound exception if any of
>>>> requested classes is missing.
>>>>
>>>>    But, in upcoming modular JDK classes that not belong to
>>>> java.lang.management (sun.management, com.sun.management etc) might not
>>>> be present.
>>>>
>>>> Solution:
>>>>
>>>>    Refactor class resolving code to support two type of classes -
>>>> REQUIRED
>>>> (still throw NCDFE if the class is missing) and OPTIONAL (just return
>>>> NULL).
>>>>
>>>>     I introduced a new parameter to highlight the fact that a class
>>>> is an
>>>> optional one on caller side rather than handle it silently inside
>>>> management.cpp.
>>>>
>>>> -Dmitry
>>>>
>>>
>>
>>
> 


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.


More information about the serviceability-dev mailing list