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). > > 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. -- Egor Pasko
