P2
kevin.kluge@Eng 1997-02-28
The monitor cache has a bug in its expansion code. When a thread expands
the cache, other threads that need monitors pile up on the expansion condvar.
When the thread expanding the cache completes, it does a notify, but not
a notifyAll. So only one of the waiting threads wakes up to get the
monitor it needs. The other waiting threads are left to wait indefinitely.
I wrote a simple program that illustrates the problem when run on a
slightly modified VM. I'll attach the program to this bug report. The
program just creates a bunch of threads that repeatedly grab a monitor,
sleep for two seconds, and release the monitor. Each thread grabs a
different monitor, so the number of requested monitor is controlled by
the number of created threads.
I modified the VM in two ways to make the problem easily reproducible.
I modified the VM so that the monitor cache expansion sleeps for 2
seconds in monitorCacheExpand(). This is so that expansions will take
long enough for multiple threads to pile up in the wait on the
expansion condvar. (This could happen on preemptive thread schedulers,
but it's hard to reproduce that way.) I also changed the code to only
add 1 monitor to the allocated pool for each expansion
(EXPANSION_QUANTUM = 1). This is so that there will be a lot of expansions.
I will attach the output of the program to this bug report. The first
output is with notify (not notifyAll). Notice that only two threads are
making progress. These are the thread that originally did the expansion
and the one thread that it woke up when it completed. The end of the
output has a dump from the VM -- notice that all the other 98 threads
are piled up in a wait on the expansion condvar.
The second output is from replacing notify with notifyAll (creating
EXPANSION_NOTIFYALL, called in place of EXPANSION_NOTIFY). Notice
that all the threads are making progress, and only a few are waiting
on the expansion condvar. There are a few waiting because the expansion
takes two seconds.
The monitor cache has a bug in its expansion code. When a thread expands
the cache, other threads that need monitors pile up on the expansion condvar.
When the thread expanding the cache completes, it does a notify, but not
a notifyAll. So only one of the waiting threads wakes up to get the
monitor it needs. The other waiting threads are left to wait indefinitely.
I wrote a simple program that illustrates the problem when run on a
slightly modified VM. I'll attach the program to this bug report. The
program just creates a bunch of threads that repeatedly grab a monitor,
sleep for two seconds, and release the monitor. Each thread grabs a
different monitor, so the number of requested monitor is controlled by
the number of created threads.
I modified the VM in two ways to make the problem easily reproducible.
I modified the VM so that the monitor cache expansion sleeps for 2
seconds in monitorCacheExpand(). This is so that expansions will take
long enough for multiple threads to pile up in the wait on the
expansion condvar. (This could happen on preemptive thread schedulers,
but it's hard to reproduce that way.) I also changed the code to only
add 1 monitor to the allocated pool for each expansion
(EXPANSION_QUANTUM = 1). This is so that there will be a lot of expansions.
I will attach the output of the program to this bug report. The first
output is with notify (not notifyAll). Notice that only two threads are
making progress. These are the thread that originally did the expansion
and the one thread that it woke up when it completed. The end of the
output has a dump from the VM -- notice that all the other 98 threads
are piled up in a wait on the expansion condvar.
The second output is from replacing notify with notifyAll (creating
EXPANSION_NOTIFYALL, called in place of EXPANSION_NOTIFY). Notice
that all the threads are making progress, and only a few are waiting
on the expansion condvar. There are a few waiting because the expansion
takes two seconds.