Weldon Washburn wrote:
On 1/11/07, Salikh Zakirov <[EMAIL PROTECTED]> wrote:
>> >> 2)
>> > >> Why not simply hard code DRLVM to throw an OOME whenever there
are
>> > >> more than
>> > >> 1K threads running? I think Rana first suggested this approach.
>> > >> My guess
>> > >> is that 1K threads is good enough to run lots of interesting
>> > >> workloads. My
>> > >> guess is that common versions of WinXP and Linux will handle
the C
>> > >> malloc()
>> > >> load of 1K threads successfully. If not, how about trying 512
>> > >> threads?
I've tried a quick-and-dirty patch to limit the number of threads to 500,
and it indeed fixes crashes on MegaSpawn.
This is good news. Thanks for trying this out. One question. Does DRLVM
handle OOME properly and gracefully when threads are limited to 500?
If you look in another message in this thread, the investigation shows
that breaks the test. It if the fact that there is *really* no memory
left, and other allocations fail. This leads to crashes and hangs.
Limiting threads number in this case creates a false OOME for
Thread.start because actually there is more virtual memory available,
and so allocating it is possible. In this case all you'll see is many
OOME stack traces, but the test won't crash on hang.
This is not a valid solution however because hitting memory limit may
happen with 500 just the same if you configure OS to create threads with
default stack of 100Mb, or it can happen because there is no available
memory because of another reason.
I would very much like if we fix this stress test correctly and do one
step towards the right handing of OOME condition.
--
Gregory
