harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexey Varlamov" <alexey.v.varla...@gmail.com>
Subject Re: [drlvm][em64t] build fails
Date Thu, 16 Nov 2006 10:38:33 GMT
16 Nov 2006 14:48:05 +0600, Egor Pasko <egor.pasko@gmail.com>:
> 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.

>
> > > 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 :)
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...

>
> --
> Egor Pasko
>
>

Mime
View raw message