gcl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gcl-devel] Re: 2.7.0 and OS X


From: Mike Thomas
Subject: Re: [Gcl-devel] Re: 2.7.0 and OS X
Date: Sun, 12 Mar 2006 16:39:10 +1000

Hi Aurelian and Camm.

Apologies for being late with the reply.

> > What's the fixnum area ? What file should I look at to see what Mike
> > did for Windows ?
> >
>
> http://people.debian.org/~camm/gcl.jpg
>
> This is a memory layout diagram illustrating the new C defines which
> need to be correctly set in configure.  There may be some additional
> work interfacing with your customized sbrk emulation.  I haven't had
> time to look at it yet on Mac.  The idea with the fixnum area is to
> pick the largest available block of address space which could never be
> used as heap in principle.  On some machines this winds up being below
> the heap.  2.7.0 configure tries to discern bounds for these areas
> from the stack location and shared library loading address, among
> other items.  There is also a facility to lower the start of the text
> if possible via a linker script to give more room.  Perhaps Mike might
> comment on what he did for Windows.

I think I just hardwired the fixnum address above the maximum address
allowed to a program in Windows.

>
> Is there any possibility that we might merge the two sbrk emulation
> routines for these two platforms?

I believe that would not be a good idea because the sbrk emulation uses
completely different system specific calls across the MacOS X and Windows
boundaries.

I think that the entire memory allocation algorithm for Windows needs to be
reexamined as it reserves a large chunk of memory up front which does not
work well with external DLL's which usually have their own memory
allocation.  I don't fully understand how the current system interacts with
unexec either, so there is an enormous amount of work required there.

Not to mention the need for making GCL thread safe if it is to take full
advantage of the current breed of multicore processors on systems without
fork().

Cheers

Mike Thomas





reply via email to

[Prev in Thread] Current Thread [Next in Thread]