On Jan 11, 2007, at 3:08 PM, Gregory Shimansky wrote:
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.
+1
Also, note that talking about virtual memory is pointless. Malloc
fails. it doesn't matter if there is virtual memory or not - we're
out of memory.
I'm impressed how fast so much clear analysis happened already...
geir
--
Gregory
