On Wednesday 26 July 2006 22:41 Weldon Washburn wrote: > On 7/26/06, Gregory Shimansky <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]