On the 0x223 day of Apache Harmony Gregory Shimansky wrote: > Egor Pasko wrote: > > On the 0x223 day of Apache Harmony Gregory Shimansky 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'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. > >> Well if you run StackTest on RI on a machine which doesn't have any > >> stack limit imposed by OS you'll still see SOE quite soon. So RI has a > >> limited stack size anyway. > > can anything stop us from doing the same? > > I don't think that anything does, we just need to agree on a > reasonable stack size default. On RI and BEA it seems to be different, > StackTest gives pretty different results.
howabout arithmetic mean? :) Seriously, I do not see a big problem here. -- Egor Pasko
