On the 0x223 day of Apache Harmony Geir Magnusson, Jr. wrote: > Egor Pasko wrote: > > 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'm not sure I meant that as a literal fork, but rather a spawned > process in which we can set the ulimit indep of the invoking parent.
actually, there is no need of a fork() or an extra process to limit stack size, I just found the "man 2 setrlimit" :) > > > >>> 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. > > I think that it's totally unreasonable to have no upper bound on stack > size. A Java virtual machine should never be able to hose a machine > by sucking in all memory... > > geir > > > > > -- Egor Pasko
