harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: [drlvm][em64t] build fails
Date Thu, 16 Nov 2006 14:41:48 GMT


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.

>  
>>> 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


> 

Mime
View raw message