harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Egor Pasko <egor.pa...@gmail.com>
Subject Re: [drlvm][em64t] build fails
Date Thu, 16 Nov 2006 10:56:55 GMT
On the 0x223 day of Apache Harmony Alexey Varlamov wrote:
> 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.

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


Mime
View raw message