Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (herse.apache.org: domain of gcjhd-harmony-dev@m.gmane.org
 designates 80.91.229.2 as permitted sender)
To: harmony-dev@incubator.apache.org
From: Egor Pasko <egor.pasko@gmail.com>
Subject: Re: [drlvm][em64t] build fails
Date: 16 Nov 2006 21:07:30 +0600
Lines: 64
Message-ID: <ud57nwhu5.fsf@gmail.com>
References: <4554E6B2.7090001@apache.org>
 <200611110153.19120.gshimansky@gmail.com>
 <e0f125db0611101536y635d7f81lfe5af4ef4278424a@mail.gmail.com>
 <200611110312.50644.gshimansky@gmail.com> <eja3pq$srf$1@sea.gmane.org>
 <783bf8b0611131123h3a881a4bvdfc64e156af1c4c6@mail.gmail.com>
 <ejagrg$khk$1@sea.gmane.org>
 <783bf8b0611140856n3131b772p32a26fcde68c16e3@mail.gmail.com>
 <ejd1qc$v1b$1@sea.gmane.org> <455A5E1D.5040300@pobox.com>
 <ejf0p8$s3f$1@sea.gmane.org> <455B9354.1070200@pobox.com>
 <ejg4pl$3ti$1@sea.gmane.org> <455B99F3.2050007@pobox.com>
 <uhcwzydyy.fsf@gmail.com> <455C78AC.30602@pobox.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3
Sender: news <news@sea.gmane.org>

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