RFR (M): JDK-8159262: Walking PackageEntry Export and ModuleEntry Reads Must Occur Only When Neccessary And Wait Until ClassLoader's Aliveness Determined
Lois Foltan
lois.foltan at oracle.com
Mon Jun 27 20:50:31 UTC 2016
On 6/27/2016 12:03 PM, Zhengyu Gu wrote:
> Hi Lois,
>
> I have a question:
>
> classLoaderData.cpp # 1004 - 1013
>
> If there is no class loader unloaded, (for example, _unloading ==
> NULL), do you still need to execute this purge loop?
Hi Zhengyu,
Thank you for the review. I have addressed your concern by moving the
purge loop into the following conditional that only executes "if
(seen_dead_loader)", nice catch. This updated webrev also contains an
improvement to the test ModuleStress.java to include a module defined to
a custom system class loader, specified via -Djava.system.class.loader.
http://cr.openjdk.java.net/~lfoltan/bug_jdk8159262.2/webrev/
Thanks,
Lois
>
> Thanks,
>
> -Zhengyu
>
> On 06/22/2016 10:51 AM, Lois Foltan wrote:
>>
>> On 6/22/2016 8:56 AM, Alan Bateman wrote:
>>>
>>>
>>> On 22/06/2016 13:51, David Holmes wrote:
>>>>
>>>> How do you envisage any system classloader "dying" ??
>>> The system class loader (be it the built-in application class loader
>>> or a custom system class loader configured via
>>> -Djava.system.class.loader) will/can never be GC'ed.
>>> ClassLoader.getSystemClassLoader() always returns a reference to it
>>> (for example).
>> Ahh, ok, I was being overly cautious, so no opportunity to reset the
>> system class loader dynamically at all?
>> SystemDictionary::_java_class_loader is not initialized until after
>> the module system initialization is complete. Due to this I have
>> updated my webrev to check for either the built-in application class
>> loader or a custom system class loader and have renamed the method to
>> is_system_class_loader().
>>
>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8159262.1/webrev/
>>
>> Thanks,
>> Lois
>>
>
More information about the hotspot-dev
mailing list