JDK-6232010 : ObjectOutputStream.subclassAudits SoftCache prevents ClassLoader GC
- Type: Bug
- Component: core-libs
- Sub-Component: java.io:serialization
- Affected Version: 1.4.2
- Priority: P3
- Status: Resolved
- Resolution: Fixed
- OS: windows_2000
- CPU: x86
- Submitted: 2005-02-23
- Updated: 2011-02-16
- Resolved: 2005-09-20
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.
| Other | JDK 6 |
|---|---|
| 5.0u7Fixed | 6 betaFixed  |
Description
FULL PRODUCT VERSION : java version "1.4.2_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_06-b03) Java HotSpot(TM) Client VM (build 1.4.2_06-b03, mixed mode) ADDITIONAL OS VERSION INFORMATION : Microsoft Windows 2000 [Version 5.00.2195] A DESCRIPTION OF THE PROBLEM : This problem is similar to that reported in 4405807. When I have a subclass of ObjectOutputStream or ObjectInputStream loaded through a ClassLoader that is later thrown away, the SoftCache in field subclassAudits of both ObjectInputStream and ObjectOutputStream won't let go of the Class object for the stream subclass, and subsequently the ClassLoader that loaded it. The system runs out of memory on few occurrences of reloading the stream subclass through new ClassLoader-s. In very rare circumstances the class and the class loader will be released, but for this to happen both conditions below must be satisfied: a) low enough level of free memory so that soft references are cleared b) but still high enough memory level so that next time code is reloaded and the subclass of ObjectOutputStream initialized, the SoftCache.processQueue() runs without running into OutOfMemoryError first. A solution to the problem would be to replace the SoftCache with a WeakHashMap. I'd also recommend you revisit the use of the SoftCache across all the JDK code, as together with 4405807, this is at least the second case of it causing trouble. I just checked, and 1.5.0 source code for ObjectOutputStream still uses SoftCache. REPRODUCIBILITY : This bug can be reproduced always. ###@###.### 2005-2-23 05:20:54 GMT
Comments
|