harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregory Shimansky <gshiman...@gmail.com>
Subject Re: Stack Overflow Error support issues
Date Wed, 26 Jul 2006 18:18:07 GMT
On Wednesday 26 July 2006 20:05 Rana Dasgupta wrote:
> In general, I am not too keen to implement a feature to mitigate a bug. I
> also think that we need some real usage based test cases for SOE failure (
> not our dev tests for unbounded recursion which force it to happen )
> to understand how serious the problem is in usage scenarios. Most server
> environments eg., web servers, recycle host processes, so I have some
> doubts on how often this kind of resource scarcity problem really occurs.
> Thread stacks are also not shared resources, even on clients. Anyway, we
> may want to wait till Harmony identifies some signature apps or benchmarks
> and we see failures due to SOE. In the meantime, my suggestion/vote would
> be to proactively check for exception state in unwindable code sections in
> the jit, or when returning from suspension state in the VM. That would be
> my 2 cents.

To make SOE more likely to happen in real applications it is easy to 
use "ulimit -s" command to limit the stack size to some small value. The 
default on Linux is 8Mb which is quite a lot.

Both drlvm and Sun VM honor this stack limit and it is possible to make even 
the very simple applications to fail on stack shortage or even crash the VM 
(Sun crashes too) when stack is very small like 32Kb.

Also playing with ulimit -s it is possible to try to catch situations when SOE 
happens in VM code like in JIT or class loader.

-- 
Gregory Shimansky, Intel Middleware Products Division

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message