Review request: 8008549: NPG: SystemDictionary::find(...) unnecessarily keeps class loaders alive
karen.kinnear at oracle.com
Tue Feb 26 09:21:21 PST 2013
The fix looks good.
Thank you for catching that!
On Feb 26, 2013, at 8:46 AM, Stefan Karlsson wrote:
> Thanks for the review.
> On 02/26/2013 02:18 PM, Coleen Phillimore wrote:
>> This is a really clean fix and thank you for finding one of the causes of the problem.
>> On 2/21/2013 11:57 AM, Stefan Karlsson wrote:
>>> This change fixes a bug, which showed up as a regression in our Jetty footprint regression testing. The bug prevents the young GCs from reclaiming some java.util.zip.Inflaters, which in turn holds on to 7 KB of native memory each.
>>> Description from the bug report:
>>> Before the PermGen removal a class loader could be garbage collected by a young GC if it didn't load any classes and all references to it were dropped.
>>> After the PermGen removal, there's an unnecessary call to register_loader in the SystemDictionary::find(...) function:
>>> ClassLoaderData* loader_data = register_loader(class_loader, CHECK_NULL);
>>> which prevents these kind of class loader from being garbage collected by the young GCs.
>>> Fortunately, we don't have to register a ClassLoaderData for the class loader in the find(...) function. The rational is that if we haven't already setup a ClassLoaderData for the class loader, then it won't have an entry in the dictionary, and we can safely return NULL.
>>> This bug is one of the reasons for the memory footprint regressions seen in:
>>> JDK-8001590: NPG: Footprint increase when running Jetty
>>> StefanK & Erik Helin
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the hotspot-runtime-dev