RFR (M): JDK-8159262: Walking PackageEntry Export and ModuleEntry Reads Must Occur Only When Neccessary And Wait Until ClassLoader's Aliveness Determined

[David Holmes]

On 22/06/2016 9:10 PM, Lois Foltan wrote:
>
> On 6/22/2016 1:15 AM, David Holmes wrote:
>> On 22/06/2016 2:21 PM, Mandy Chung wrote:
>>>
>>>> On Jun 21, 2016, at 8:43 PM, David Holmes <david.holmes at oracle.com>
>>>> wrote:
>>>>
>>>> On 22/06/2016 1:33 PM, Mandy Chung wrote:
>>>>> Platform class loader [1] is previously known as the extension
>>>>> class loader.  We have deprivileged several Java SE modules to be
>>>>> defined by the platform class loader instead of the boot loader.
>>>>> They are not granted with all permissions by default. The class
>>>>> spec of ClassLoader has a section [2] to describe the built-in
>>>>> class loaders.
>>>>
>>>> Thanks Mandy. I was surprised to see the addition of code to query
>>>> if the application classloader as we have always had such code:
>>>>
>>>> SystemDictionary::java_system_loader()
>>>>
>>>> So AFAICS this addition is not needed:
>>>>
>>>> 178 // Returns true if the passed class loader is the application
>>>> class loader.
>>>> 179 bool SystemDictionary::is_application_class_loader(Handle
>>>> class_loader) {
>>>> 180   if (class_loader.is_null()) {
>>>> 181     return false;
>>>> 182   }
>>>> 183   return (class_loader->klass() ==
>>>> SystemDictionary::jdk_internal_loader_ClassLoaders_AppClassLoader_klass());
>>>>
>>>> 184 }
>>>>
>>>
>>> This might be better to rename it to is_builtin_application_loader?
>>
>> Maybe ...
>
> First, thank you Mandy and David for reviewing.  I actually like the
> suggestion of renaming this method to is_builtin_application_loader with
> added comments in SystemDictionary::is_builtin_application_class_loader
> as to why exactly the check is against
> SystemDictionary::jdk_internal_loader_ClassLoaders_AppClassLoader_klass
> and not _java_system_loader.
>
>>
>>>> But for that matter why do we have
>>>> SystemDictionary::jdk_internal_loader_ClassLoaders_AppClassLoader_klass
>>>> and SystemDictionary::java_system_loader ? They are, or should be,
>>>> the same thing.
>>>>
>>>
>>> In almost all cases except when -Djava.system.class.loader is set to
>>> a custom class loader:
>>>
>>> java_system_loader may be a custom system class loader which is not
>>> an instance of jdk_internal_loader_ClassLoaders_AppClassLoader_klass.
>>
>> ... so we're not really asking if it is the system/application loader
>> but if it is a particular type of classloader that is fulfilling that
>> role?
>>
>> Which then begs the question as to what we are doing that depends on a
>> specific type of classloader and what we do if not dealing with such a
>> type ??
>
> For this RFR's that differentiation is important.  If someone defines
> their own system/application loader, I suspect then that they have
> control over its life cycle.  The fact that it will not die during the
> application's life can not be assumed.  Thus any modules defined to that
> custom system/application loader may indeed die and need to get purged
> from packages' export or modules' reads lists.

How do you envisage any system classloader "dying" ??

David


> Thanks,
> Lois
>
>>
>> Thanks,
>> David
>>
>>> Mandy
>>>
>