Bug ID: JDK-4730581 Hopper will consume all the heap memory lastly

Type: Bug
Component: client-libs
Sub-Component: java.beans
Affected Version: 1.4.1

Priority: P2
Status: Closed
Resolution: Not an Issue
OS: windows_2000
CPU: x86

Submitted: 2002-08-13
Updated: 2002-08-13
Resolved: 2002-08-13

THis is a Regression from Merlin..  

Memory leak seems to happen to 1.4.1-rc-b19(windows)

Originally, OutOfMemory happens to a licensee's system in 1.2.2 and 1.3.1.
With further investigation, they concluded the similar issue might be happen 
in 1.4.1b19. Please evaluate.

1. reproduce & behavior

 1) Unfold the attached file
   -> you will see the GetPropertyK.java, GetPropertyK.class and aaa dir.
      under aaa, you can see TestBean.java and .class.
      Those .class files are compiled 1.3.1_04.
 2) Invoke "java -verbose:class GetPropertyK" in 1.3.1_04, 1.4.0_01
    and 1.4.1-rc-b19.
    
 3) in 1.3.1_04 and 1.4.1-rc-b19, logs will be output as follows.
   
     ....
      [Loaded TestBean]
      [Loaded TestBean]
      [Loaded TestBean]
      [Loaded TestBean]   
        .....
   
    On the other hand, the output will be as follow in 1.4.0_02.
   
      [Loaded TestBean]
      [Unloading class TestBean]
      [Loaded TestBean]
      [Unloading class TestBean]  
      
   
2. Investigation

Actually, OutofMemory happens in 1.3.1_04 with long time run on the customer's
site. This seems to be from that JVM does not unload the loaded TestBean.
On the other hand, it does not happens in 1.4.0_01 because it releases 
TestBean class.

If the above is correct, because the JVM of 1.4.1-rc-b19 does not unload 
the TestBean, OutofMemory will happens in 1.4.1-rc-b19.

3. Configration

  MPU: Pentium IV 1.4 [GHz]
  OS : Windows 2000(SP2, Japanese)
  JRE/JDK: 1.4.1-rc-b19/1.3.1_04

4. Note
 1) I recommend to run with -Xmx6M. If you run with default value(64M),
    it will take much time to confirm this behavior.
    With such small max heap size, job will terminate in 5 minutes
    (at longest) with OutOfMemory in 1.4.1-rc-b19.
    In 1.4.0_01, job did not terminate even with such small heap size.
    
 2) OptimizeIT, the behavior of 1.4.1b19 is apparently different
    from that of 1.4.0_01.(1.4.1b19 keep consuming the heap.)
    Please see the attached screen shots.
    

2002-08-13
===========================================================================

EVALUATION Error as stated in description occurs on sparc as well. JDK 1.4.1_b19 Need to look at testcase to see if that is valid. ###@###.### 2002-08-13 Re-assigning to beans team for further eval.. ###@###.### 2002-08-13 This issue exists because the main() loop in GetPropertyK instantiates and uses a new ClassLoader on each loop iteration. The BeanInfo in the static cache is associated with the ClassLoader. When the class loader is gc'd, a reference to the BeanInfo is strongly held even though the key (the Bean class) has been gc'd when the class loader goes away. The SoftReferences wrappers were added to the internal static caches in the Introsepector to fix the orignal bug 4291376 and the escalation 4508780. After 1.4 was released, it was determined that the garbage collection of BeanInfos was too aggressive and make the BeanInfo caching mechanism unreliable for XML long term persistence and would bog the performance of the Introspector. The SoftReference wrappers were removed in response to fixing the bug 4646747 in hopper. For applications which use multiple classloaders and BeanInfo, you should call the static methods Introspector.flushCaches() or Introspector.flushFromCache(Class) to remove the classes from the static class when the custom ClassLoader is removed. Since this problem exists for class loaders which have shorter lives than the application and the semantics of 1.4.1 is the same as for 1.3.1, this is not a bug. The 1.4.1 javadoc for the Introspector describes the issue of using multiple classloaders and flushing the classes. ###@###.### 2002-08-13 A licensee wants us to improve current static cache model. They point out that J2EE app servers (including RI) use many class loaders. For example, when a user updates a JSP file, a container has to compile it and load it by a new class loader each time. However, containers does not know if Introspector is used or not. If SoftReferences causes bug, could you please create another way to solve it? ###@###.### 2002-08-28

28-08-2002

WORK AROUND This isn't a work around so much as a description about using the BeanInfo caching with short lifetime classloaders. At the end of each loop iteration in GetPropertyK, before all the local variables are nulled out, add the call Introspector.flushFromCache(c); or Introspector.flushCaches(); ###@###.### 2002-08-13

13-08-2002

Relates :	JDK-4809008 - Introspector cache should be cleared without explicit flush methods calls
Relates :	JDK-4779460 - OutOfMemory happens when the perm heap is filled by softly referenced objects