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 14:47:48 GMT
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


Mime
View raw message