Re: [Gcl-devel] mac os x port questions

[Camm Maguire]

Greetings!

Aurelien Chanudet <address@hidden> writes:

> I was able to solve the case during the week-end : GCL is now running
> back again. Still, I've got a few questions to craft as optimal a
> solution as possible.
> 

Great!

>  > 2) I really think it would be best to not hardwire the heap size, but
>  >   rather take the value from MAXPAGE*PAGESIZE set at configure time.
> 
> Thanks for the suggestion. Would the following memory layout be ok ?
> 
> +---------------------------------------+
> |    text segment as produced by gcc    |
> +---------------------------------------+ <- DBEGIN
> |    data segment as produced by gcc    |
> | (including .bss, .const and the like) |
> +---------------------------------------+ <- sbrk(0)
> |  wiggle room to allocate memory from  |
> +---------------------------------------+ <- DBEGIN + MAXPAGE*PAGESIZE
> 

This should be fine, especially if the data segment as produced by gcc
is small as it should be.  The standard configure test tries to guess
a good value by looking at initial malloc results from a small test
program.   We could really clean this up at some point by using a
static variable. 

>  > 3) Your strategy in my_sbrk should work, but will result in the
>  >   maximum image size for all applications regardless of complexity.
>  >   I don't know if your virtual memory system can realloc the heap
>  >   without moving, but if so this would be preferable.
> 
> That is, I should try increasing the size of the image little by
> little, as opposed to allocating a huge block of memory at
> initialization time, if possible ? The issue here is that I cannot
> figure out how to make sure that room needed is there without
> allocating it.
> 

OK, if this is not easy its not critical.

>  > 4) The example below, where you appear to have shrunk the heap
>  >   substantially, is indeed too small.  At the very minimum, there has
>  >   to be holesize+ (reloc pages) between heap_end and core_end.
>  >   Holesize defaults to 1/10 MAXPAGE, so we see here again that we'll
>  >   have less headaches using these macros where possible.
> 
> Sorry for such a basic question: what area is actually called the hole
> ? In the draft above, where would heap_end and core_end actually point
> to ?
> 

DBEGIN
first sbrk(0)
...
heap_end
hole
relocatable blocks
core_end (max at DBEGIN+MAXPAGE*PAGESIZE)

On Linux, the heap grows into the hole, until it can no more, at which
point the relocatable area is gc'ed, the core size is increased with
sbrk, the reloc area moved to the new end, and the space between the
old heap end and the new reloc area is the new hole.

>  > Will your DBEGIN vary at compile time?  If so, is it correctly
>  > detected and propagated by configure?
> 
> No problem here.
> 
>  > Also, how does configure
>  > autodetect your machine type?  We can modify configure.in to set the
>  > --enable-machine variable automatically.
> 
> My machine is detected as powerpc-*-darwin*. I'll will come back with
> a patch for configure.in.
> 

Great!

> Thanks !
> 

Take care,

> 
> 
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gcl-devel
> 
> 
> 

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