JDK-8008549 : NPG: SystemDictionary::find(...) unnecessarily keeps class loaders alive
- Type: Bug
- Component: hotspot
- Sub-Component: runtime
- Priority: P3
- Status: Closed
- Resolution: Fixed
- Submitted: 2013-02-20
- Updated: 2014-06-26
- Resolved: 2013-02-27
The Version table provides details related to the release that this issue/RFE will be addressed.
Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.
To download the current JDK release, click here.
Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.
To download the current JDK release, click here.
| JDK 8 | Other |
|---|---|
8Fixed  |
hs25Fixed |
Related Reports
|
Relates :
|
Description
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
Comments
|