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 21:09:25 GMT
On Wednesday 26 July 2006 22:41 Weldon Washburn wrote:
> On 7/26/06, Gregory Shimansky <gshimansky@gmail.com> wrote:
> > 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.
> All good points.  Forcing the JVM into an SOE condition, then
> analyzing what happens is a valuable tool.  However, it is more
> important to know when/where the JVM runs into SOE problems with real
> workloads.  And what we need to do to address this particular
> situation.  While it is conceivable that real workloads could cause
> substantial redesign to make SOE work as expected, we need to be
> convinced this is indeed the situation.  In other words, premature
> overengineering is the little brother of premature optimization.

Yes I agree completely. I just offered a way to analyze the real world 
scenarios in stressed stack conditions. Because in default 8Mb stack I don't 
remember any Java or C real world application hitting the stack limit (maybe 
except for some of those that I worked on :) ).

Making stack shorter may allow to compare stability of Harmony VMs and RI on 
real applications, and if some investigation is done we can then make a 
decision what actually needs improvement.

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

View raw message