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 Wed, 10 Jan 2007 13:51:11 GMT
Geir Magnusson Jr. wrote:
>> I am not sure that we need to do something about this. The default 
>> initial
>> stack size on Windows is 1M,
> Yikes!  There's our problem on windows...

The same OOME is thrown on Linux as well, but I am not sure if it 
happens because of reaching virtual space limit or because of some other 
reason. I don't have a good process monitor for Linux to see the number 
of running threads and virtual memory size.

>> and that is the recommended init size for real
>> applications. The fact that our threads start with a larger intial stack
>> mapped( default ) than RI is a design issue, it is not a bug. We could 
>> start
>> with 2K and create many more threads!
> That's right.  The fact that the VM crashes and burns is the bug, and a 
> serious one, IMO.
>> We should not use this test ( which is not a
>> real app ) as guidance to tune the initial stack size. My suggestion 
>> is to
>> lower the test duration so that we can create about a 1000( or whatever
>> magic number ) threads at least. That is the stress condition we 
>> should test
>> for.
> The big thing for me is ensuring that we can drive the VM to the limit, 
> and it maintains internal integrity, so applications that are designed 
> to gracefully deal with resource exhaustion can do so w/ confidence that 
> the VM isn't about to crumble out from underneath them.

I agree with Geir that we should try to handle out of C heap condition 
gracefully. The problem is that there is no clearly defined contract for 
many functions that use memory allocation about what to do in case of 
out of memory condition.

To maintain integrity all VM functions which allocate memory from C heap 
should return gracefully all the way up the stack until they hit Java 
code that called them and then OOME exception shall be seen by the Java 
code. It is not an easy task because all code paths should support it, 
including JIT and GC.


View raw message