harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregory Shimansky <gshiman...@gmail.com>
Subject Re: [drlvm] stress.Mix / MegaSpawn threading bug
Date Thu, 11 Jan 2007 20:08:46 GMT
Weldon Washburn wrote:
> On 1/11/07, Salikh Zakirov <Salikh.Zakirov@intel.com> 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


Mime
View raw message