Siebel calls for Inflater and Deflater object in the following way
* insider a method a new Deflater object is created and assigned to a local reference.
* Deflation takes place immediately, end() not called
* After deflation local reference goes out of scope when method exists, object is available for GC.
* This method is called many times (each time a new Deflater is constructed and discarded).
* Each time, buffer size is in the order of 1K (not exact).
A possible, but unlikely reason ("Unlikely reason") could be: GC bug, when the count of Delater/Inflater objects available for GC but not yet GCed is continuously increasing.
Alternatively the native implementation has memory leaks, as it does not stand to reason that continuous memory growth is caused by "Unlikely reason", but rather as a result of native memory not properly released in some cases.
I have suggested that a explicit end() be included in code but Siebel says that memory growth continues with end() call too.
###@###.### 2005-07-02 02:27:13 GMT
User sends a new test case to replicate the problem.
The test case is enclosed.
(moved comments to Comments section.)
* insider a method a new Deflater object is created and assigned to a local reference.
* Deflation takes place immediately, end() not called
* After deflation local reference goes out of scope when method exists, object is available for GC.
* This method is called many times (each time a new Deflater is constructed and discarded).
* Each time, buffer size is in the order of 1K (not exact).
A possible, but unlikely reason ("Unlikely reason") could be: GC bug, when the count of Delater/Inflater objects available for GC but not yet GCed is continuously increasing.
Alternatively the native implementation has memory leaks, as it does not stand to reason that continuous memory growth is caused by "Unlikely reason", but rather as a result of native memory not properly released in some cases.
I have suggested that a explicit end() be included in code but Siebel says that memory growth continues with end() call too.
###@###.### 2005-07-02 02:27:13 GMT
User sends a new test case to replicate the problem.
The test case is enclosed.
(moved comments to Comments section.)
- duplicates
-
JDK-6410143 Out of memory in web application with JVM 1.4.2_05/1.4.2_08
- Closed
- relates to
-
JDK-5072161 OutOfMemoryError while using GZIPOutputStream
- Closed
-
JDK-6976467 Class unloading not happening promptly enough, causing OOM in perm gen
- Closed
-
JDK-7010249 Many ParallelClassLoadingTests fail with "Too Many Open Files"
- Closed