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 15:07:30 GMT
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


Mime
View raw message