RFR(S): 8185694: Replace SystemDictionaryShared::_java_platform_loader with SystemDictionary::is_platform_class_loader()
David Holmes
david.holmes at oracle.com
Fri Oct 6 01:33:55 UTC 2017
Hi Coleen, Calvin,
On 6/10/2017 6:54 AM, coleen.phillimore at oracle.com wrote:
> So if you use -Djava.system.loader=myLoader on the command line, setting
> _java_system_loader, then does that mean that the classes loaded by
> SystemDictionary::jdk_internal_loader_ClassLoaders_AppClassLoader_klass() are
> not in the system loader? ie. they can be unloaded? What is the result
> of the call to SystemDictionary::is_system_class_loader() used for? I
> guess same question applies to the platform class loader.
The classloading delegation hierarchy (as of JDK 9) is:
- boot loader (native)
- platform loader (built-in)
- system (aka application) loader (built-in)
If the user specifies a custom class for the system loader then it is
loaded by an instance of the default system loader and becomes a fourth
level in the hierarchy, and it is then technically the "system loader".
None of these loaders, or the classes they load can be unloaded.
Which is presumably why the code checks both:
180 bool SystemDictionary::is_system_class_loader(oop class_loader) {
181 if (class_loader == NULL) {
182 return false;
183 }
184 return (class_loader->klass() ==
SystemDictionary::jdk_internal_loader_ClassLoaders_AppClassLoader_klass() ||
185 class_loader == _java_system_loader);
186 }
because we need to treat both of these instances as the "system loader"
from a VM perspective? The same does not apply to the platform loader.
David
-----
> thanks,
> Coleen
>
>>
>>> The implementation is in closed source.
>> Please clean up the closed code to remove those.
>>
>>
>> Thanks,
>>
>> Jiangli
>>
>>>> Is this new java_platform_loader function used anywhere?
>>> Yes, it is being used in closed source.
>>>> Currently
>>>> SystemDictionary::jdk_internal_loader_ClassLoaders_PlatformClassLoader_klass
>>>> is preloaded. Shouldn't this be removed? What about
>>>> jdk_internal_loader_ClassLoaders_AppClassLoader?
>>> They're being used in lines 184 and 193 in systemDictionary.cpp and
>>> also in closed source.
>>>> thread.cpp
>>>>
>>>> 3752 SystemDictionary::compute_java_loaders(CHECK_(JNI_ERR));
>>>>
>>>> What is the difference between CHECK_(JNI_ERR) vs CHECK_JNI_ERR?
>>>> Should it simply use CHECK_JNI_ERR as in other places?
>>> They are the same, in utilities/exceptions.hpp:
>>> #define CHECK_JNI_ERR CHECK_(JNI_ERR)
>>>
>>> and it expands to the following:
>>> __the_thread__); if
>>> ((((ThreadShadow*)__the_thread__)->has_pending_exception())) return
>>> (-1); (void)(0
>>>
>>> I can change it to CHECK_JNI_ERR.
>>>
>>> thanks,
>>> Calvin
>>>> Mandy
>
More information about the hotspot-runtime-dev
mailing list