On the 0x223 day of Apache Harmony Alexey Varlamov wrote: > 16 Nov 2006 14:48:05 +0600, Egor Pasko <[EMAIL PROTECTED]>: > > On the 0x223 day of Apache Harmony Geir Magnusson, Jr. wrote: > > > Gregory Shimansky wrote: > > > > Geir Magnusson Jr. wrote: > > > >> > > > >> > > > >> Gregory Shimansky wrote: > > > >>>> > > > >>> -Xss is the lower stack limit, it doesn't specify the maximum > > > >>> stack size, doesn't it? > > > >> > > > >> What does "lower stack limit" mean? :) I think that it's the size > > > >> of the stack, max. > > > > I thought it is a starting stack size, like -Xms for heap size. Now > > > > that I searched the web it appears that it is the maximum indeed. > > > > > > "0" is minimum stack size. > > > > > > > > > > >> I think all you need to do then is set the stack size : > > > >> > > > >> ulimit -s 8192 > > > >> > > > >> or something. We should probably do this before each run on linux > > > >> so that things are well defined and reproducible. > > > > I think 64-bit SuSE9 is just the only weird distribution which > > > > doesn't have this limit. In 10th version they fixed this. So ulimit > > > > -s is not necessary in most cases. > > > > > > But harmless. And it makes the test predicable across platforms. and > > > if the StackSize test is forked, we can make it small to make it > > > quick... > > > > I know nothing about forking Java processes. Does it make sense? > > Secondly, fork() is fast regardless of the stack size (stacks are COW). > > Determinative time here is test execution time, not forking time. The > point is to make SOE happen quickly instead of stressing host machine.
yes the most elegant would be to run the test in a separate VM with small -Xss > > > > > > I'd still like to have a recursion limit in StackTest but Rana has > > > > convinced me that no SOE shouldn't mean that test has failed. I'll > > > > patch it now. > > > > > > > > > > I agree that your fix is utterly bogus :) but we want to test SOE > > > machinery, so I think that we should set the ulimit to ensure an > > > environment in which the SOE will happen if DRLVM is working > > > right. Therefore, we need to set things up such that not getting an > > > SOE is indeed a failure. > > > > What a user would most likely expect on a system with no stack limit? > > Something like on the other systems with stack limit as in > > run-anywhere concept. And that would be SOE, not swapping. So, let's > > limit the stack by, say, 10M if not set with an option. We can > > implement the option later. > This is arguable - remember essays about users frustrated by > artificial Java heap limits :) I do :) but today is not the right time to merge JVM with OS so much. Behaving more like RI has more priority. > Another point can be slightly different meaning for -Xss on RI and > DRLVM, the latter has united stack as opposite to separate Java stack > on RI... I am not sure I understand. What is the "separate Java stack"? Does it mean that Java stack does not relate to 'ulimit -s' on RI? Why not we do the same for user convenience? -- Egor Pasko
