[Gcl-devel] Re: [Axiom-developer] RE: gcl-2.6.8pre on MAC OSX 10.2

[Camm Maguire]

Greetings!

Gabriel Dos Reis <address@hidden> writes:

> On Thu, 16 Nov 2006, Humberto Ortiz Zuazaga wrote:
> 
> | Gabriel Dos Reis wrote:
> |
> | >   How about this patch I'm testing?  I splitted the GCLOPTS into
> | > independent parts, and disabled X and TK for all targets.
> |
> | It wasn't working. I think I've finally tracked it down.
> |
> | On Mac OS X, the gcl configure option:
> |
> | --enable-maxpage=256*1024
> |
> | causes gcl to segfault immediately upon starting.
> 
> Arg.  I don't know what the proper value must be.  The above is what
> is on trunk but since nobody reported it worked I believe we must
> follow what you advise here.
> 
> Bill had a different value for that parameter (which is not a power of
> 2).  Personaly, I don't think users must get into  the business of
> fiddling with that parameter.  Ideally, GCL should just figure out
> what is the right thing to do.
> 
> | I'm building axiom now on my Mac, I'm pretty sure it's using the
> | contained gcl (the one in build/), and it seems to be working.
> 
> OK.
> 
> | What's the default size for this parameter? I'm going to try 128*1024 to
> | see if it works, but it's likely pointing to some kind of memory
> | management bug, isn't it.
> |
> | The current build is working with the following configure flags:
> |
> | # ./configure
> | --prefix=/Users/humberto/src/axiom/test/build/powerpc-apple-darwin8.8.0
> | --disable-xgcl --enable-locbfd --disable-statsysbfd
> | --enable-machine=powerpc-macosx '--enable-vssize=65536*2'
> | --disable-tkconfig --disable-x
> 
> OK, maybe we should just leave out --enable-maxpage.  Camm?
> 

The short story is I'd recommend leaving out the maxpage at least on
macosx.  In fact, we might make it a configure error at the moment.

The long story is that GCL supports two platforms without OS sbrk, and
therefore emulates same -- Windows and Macosx.  GCL would use some
volunteers to help making this emulation flow more nicely with the
basic settings governing the traditional unix memory model,
e.g. maxpage in the current context.  (I've posted a pictorial
representation of GCL's memory layout -- if anyone is interested I'll
dig up the URL).

On the mac, we have in unexmacosx.c:

/* This used to be the size of the heap, but this is no longer used.  */
#define BIG_HEAP_SIZE 0x50000000

...

/* Size of the heap.  */
int big_heap = BIG_HEAP_SIZE;

...

void *my_sbrk (int incr)
{
  char               *temp, *ptr;
  kern_return_t       rtn;
  
  if (mach_brkpt == 0) {
    if ((rtn = vm_allocate (mach_task_self (), (vm_address_t *) &mach_brkpt,
                            big_heap, 1)) != KERN_SUCCESS) {
      malloc_printf ("sbrk_macosx(): vm_allocate() failed\n");
      abort ();
      return ((char *)-1);
    }
    if (!mach_brkpt) {
      /* Call this instead of fprintf() because no allocation is performed.  */
      malloc_printf ("sbrk_macosx(): cannot allocate heap\n");
      return ((char *)-1);        
    }
    mark_region ((unsigned long) mach_brkpt, (unsigned long) big_heap);
        
    mach_mapstart = mach_brkpt;
    mach_maplimit = mach_brkpt + big_heap;
  }
 ...

In the first raw image produced by gcc, the first thing the mac does
is allocate this huge block, do an image save, and then an exec to the
new image.  The emulated sbrk then steps contiguously through this
preset block until the end.  A real sbrk will continue to append pages
contiguously until the OS is oom, but this is OK (at the moment)
because GCL has maxpages as a compile time limit anyway (this will be
relaxed at some point).  Perhaps all that needs doing is making sure
big_heap and maxpage are synchronized, but I don't fully understand
the memory layout on the mac and whether there are other obstacles
that need checking for, and/or what the signs of collision might be.  

This is probably also why saved images seem larger on the mac than
necessary. 

So in sum an effective limit on --enable-maxpage on the mac at the
moment is something like 0x50000000 / PAGESIZE, which is not checked
by configure.

Other macosx issues that need some loving care by mac afficionados:

1) SGC is not working.  Aurelien ran into difficulties in the past
   getting gdb to trap segfaults properly, without which debugging
   this is almost impossible.
2) i386 support.  I posted earlier that an initial attempt shows a
   failure on launching the first saved image described above, with a
   "Cannot allocate memory" error from the OS (on an 8gb machine)
   before malloc or main are reached.  Something about the layout
   requirements for the new .data section in the saved image must have
   changed.  

I'd like not to spend too much personal time on Windows and Mac, as my
main concern here is the advanecment of free software.  That said I
will make it easy for anyone else so inclined to step in.

Take care,

> -- Gaby
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah