[ruby-core:21323] Re: [PATCH] Promising C coding techniques to reduce MRI's memory use

Stephen,

I'm very much a PowerPC newbie, so please bear with me...

Yesterday, I got an off list report that ruby with the MBARI patches was
failing with:

./lib/fileutils.rb:521: stack level too deep (SystemStackError)

after applying them on a PowerBook G4, Mac OS X 10.5.6 with apple GCC 4.0.

A kind colleague happened to have a very similar laptop I could borrow. 
This let me duplicate the failure.  It was being caused by the fact that the
rlim_t type returned by the getrlimit() call to get process limits was
*signed* rather than unsigned as under Linux.  This made my patched Ruby
believe that the size of the stack area reserved for it was 0 bytes,
triggering the "stack too deep" exception".  I fixed this and posted a
update to MBARI7 last night after fairly extensive testing.
The date on the latest version is Jan 12, 2009.

So, my first questions are:
  Did you run into this issue?  If not, why not.  If so,  did you fix or
work around it yourself?
The exact gcc being we used was:
powerpc-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5465)

Regarding your posting:
There is clearly some misleading gcc documentation out there about
-fomit-frame-pointer.
It is a machine independent option, but the exact effects of the -Ox options
are machine dependent.

If I understand you correctly, compiling with gcc and

  -fno-omit-frame-pointer

causes ruby crashes on PowerPC OSx.  Does it also
cause crashing on Intel OSx?

Are these crashes happening whether or not
the MBARI patches are applied or only after applying them?

In any case, it seems that you've managed to get the compiler and MBARI
patches 
very well optimized for PowerPC OSx.

Could you post some (brief) PPC OSx benchmark results 
comparing runtime and peak process size before and after patching, taking
care to build ruby with the same compiler options each time?

- brent


Stephen Sykes-3 wrote:
> 
> On OSX -fomit-frame-pointer is turned off if you use -O2, or other
> levels.  In fact, if you turn it on, the compiled ruby crashes.
> 
> OSX has an addition to gcc - a "-fast" option that turns on the following
> flags:
> -O3 -fomit-frame-pointer -fstrict-aliasing -momit-leaf-frame-pointer
> -fno-tree-pre -falign-loops
> 
> But as both -fomit-frame-pointer and -momit-leaf-frame-pointer cause
> the compiled ruby to crash, I have been using these options to compile
> ruby with MBARI7:
> 
> -O3 -fstrict-aliasing -fno-tree-pre -falign-loops
> 
> Also with these options I have not had any problems setting
> STACK_WIPE_SITES to 0x4370
> 
> -Stephen
> 
> On Tue, Jan 13, 2009 at 12:49 AM, Hongli Lai <[e-mail]> wrote:
>> Brent Roman wrote:
>>>
>>> That's not the way the gcc behaves in my experience with the 32-bit x86
>>> machines.
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/-ruby-core%3A19846---Bug--744--memory-leak-in-callcc--tp20447794p21447973.html
Sent from the ruby-core mailing list archive at Nabble.com.