The following is the javadoc from the example code which uncovered this bug. The product JavaSafe has a server running on the JavaServer Toolkit. After heavy use, the server was crashing with an OutOfMemory exception. This is the root cause. The java code for the example is in the Comments section of this bug report.
* <p> This program demonstrates a memory leak in Sun's JVM. A short-lived
* thread that allocates objects makes the total memory used by the program
* increase, even after the thread finishes.
*
* <p> We run an infinite loop, with each cycle running a new thread and then
* measuring the total memory in use. For the tests that exhibit the leak, the
* memory in use steadily climbs; for those that do not, the memory in use
* quickly reaches a constant level.
*
* <p> There are several different tests, each with its own static method. You
* execute the different tests by changing the code for the subsidiary thread
* to call the different methods, and then recompiling for each. The tests are
* as follows:
*
* <ul>
* <li> Test 0 does nothing, and it exhibits no leak.
*
* <li> Test 1 allocates a single Object; it exhibits the leak.
*
* <li> Test 2 is a family of tests that allocate a linked list of objects.
* Test 2a allocates 10 objects; 2b, 100; 2c, 1000; and 2d, 10000. All of
* these tests exhibit the leak.
*
* <li> Test 3 is a family of tests that allocate a single object and then
* sleep for a while. Test 3a sleeps 1 millisecond; 3b, 100 ms; and 3c, 1
* second. Tests 3a and 3b exhibit the leak, and test 3c does not.
*
* <li> Test 4 is a family of tests that allocate byte arrays of different
* sizes. Test 4a allocates an array of 1 byte; 4b, 10 bytes; 4c, 100
* bytes; and 4d, 1000 bytes. All except 4d exhibit the leak.
*
* </ul>
*
* <p> We have run tests 0 and 1 on Sun's version 1.1.5 JVMs on Solaris (both
* the green- and native-threads JVMs) and on NT; on Solaris, we have tested
* both the JDK and JRE versions. All of these JVMs exhibit the leak on test 1
* and do not on test 0. We have performed the remaining tests on the Solaris
* green-threads JRE virtual machine.
* <p> This program demonstrates a memory leak in Sun's JVM. A short-lived
* thread that allocates objects makes the total memory used by the program
* increase, even after the thread finishes.
*
* <p> We run an infinite loop, with each cycle running a new thread and then
* measuring the total memory in use. For the tests that exhibit the leak, the
* memory in use steadily climbs; for those that do not, the memory in use
* quickly reaches a constant level.
*
* <p> There are several different tests, each with its own static method. You
* execute the different tests by changing the code for the subsidiary thread
* to call the different methods, and then recompiling for each. The tests are
* as follows:
*
* <ul>
* <li> Test 0 does nothing, and it exhibits no leak.
*
* <li> Test 1 allocates a single Object; it exhibits the leak.
*
* <li> Test 2 is a family of tests that allocate a linked list of objects.
* Test 2a allocates 10 objects; 2b, 100; 2c, 1000; and 2d, 10000. All of
* these tests exhibit the leak.
*
* <li> Test 3 is a family of tests that allocate a single object and then
* sleep for a while. Test 3a sleeps 1 millisecond; 3b, 100 ms; and 3c, 1
* second. Tests 3a and 3b exhibit the leak, and test 3c does not.
*
* <li> Test 4 is a family of tests that allocate byte arrays of different
* sizes. Test 4a allocates an array of 1 byte; 4b, 10 bytes; 4c, 100
* bytes; and 4d, 1000 bytes. All except 4d exhibit the leak.
*
* </ul>
*
* <p> We have run tests 0 and 1 on Sun's version 1.1.5 JVMs on Solaris (both
* the green- and native-threads JVMs) and on NT; on Solaris, we have tested
* both the JDK and JRE versions. All of these JVMs exhibit the leak on test 1
* and do not on test 0. We have performed the remaining tests on the Solaris
* green-threads JRE virtual machine.
- duplicates
-
JDK-4102107 allocCacheCleanup() is never called for thread local storage for objects/handleW
-
- Closed
-