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

[Lois Foltan]

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.

Thanks,
Lois

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