DEC writes:
We've uncovered and fixed what looks to be a fairly serious defect in the
garbage collector for JDK 1.1.5. Examining the 1.1.6 sources we have, it
appears that the bug is present there as well.

In 1.1.5, the notion of thread local storage for objects and handles was
introduced. This can be seen in gc.c by examining the code for cacheFillBlock(),
cacheFillHandles(), cacheAlloc(), and allocCacheCleanup(). The ExecEnv
structure was modified to include a cache_list structure. When an allocation
occurs, the ExecEnv for the given thread is examined, and allocation occurs
out of those structures whenever possible.

The bug is that allocCacheCleanup() is never called. When a thread is created,
an objects allocated in support of that thread, handle space is allocated within
the cache_list maintained by that threads ExecEnv. When the thread dies, the
handles are never returned to the hpoolfreelist. The net effect is that the
program gradually "loses" handles. The garbage collector, believing that it is
out of handles, will unnecessarily increase handle space. For a very busy
program using lots of threads, the allocator will eventually fail with an out of
memory condition owing to depleted handle space, even though there are literally
thousands of handles available.

The bug that we encountered is best seen by running a small program that
creates a significant amount of threads that have very short lifetimes. The
problem exists in any 1.1.5 port unless the vendor realizes what we have found
and makes the appropriate fix. We saw this problem in a 50 line client/server
application. After 13,000 "cycles" of thread creation and lifetime, we observed
the system failing with out of memory. Subsequent investigation found 209,000
handles lying dormant in the heap. These handles were those that were allocated
to support the TLS cache_list in the ExecEnv structures.

The fix is fairly straightforward. We first modified ./src/share/java/runtime/interpreter.c
and added a call to allocCacheCleanup() in the routine DeleteExecEnv(). We
then discovered a problem in the allocCacheCleanup() code itself. The routine
declares:

         struct execenv *ee = EE();

Calling EE() at this time led to segmentation faults and core dumps. As it turns
out, the call to EE() to establish ee was superfluous in that the alloc_cache
structure is already passed from a valid execenv structure, and the ee created
by the EE() call was never used for anything. By removing the declaration and
the call to EE(), we went from exhausting handle space after 13,000 cycles, to
running over 100,000 cycles with no noticable long-term heap impact.

sandy.labrasca@eng 1999-01-12
See more info
Added DMT in program management field for 1.1.5_02 release notes.