Re: [Gnustep-cvs] r26723 - in /libs/base/trunk: ChangeLog Headers/Additions/GNUstepBase/config.h.in Source/GSFFIInvocation.m configure configure.ac

[David Chisnall]

On 30 Jun 2008, at 15:00, Richard Frith-Macdonald wrote:

> On 30 Jun 2008, at 12:33, David Chisnall wrote:
>
> > > > My man page for vmalloc states:
> > > >    The  obsolete  function  valloc()  allocates  size bytes and
> > > > returns a pointer to the allocated memory.  The memory address  
> > > > will be a
> > > > multiple of the page
> > > >    size.  It is equivalent to memalign(sysconf(_SC_PAGESIZE),size).
> > > >
> > > > I'm not sure whether you are aware of the fact that this function  
> > > > is
> > > > considered obsolete.
> >
> > Not according to POSIX, however it is recommended that applications  
> > use mmap or malloc if possible.  In our case, the ideal solution  
> > would be a dedicated, mmap-backed, NSZone for allocating invocation  
> > trampolines.
>
> Sounds good.
>
> At the moment I'm just concentrating on getting libffi working  
> reliably, but I'd love to add better performing code if you can  
> provide it.
> The idea of per-thread allocation sounds good, but even better if it  
> cold somehow be integrated with the autorelease mechanism so that we  
> can minimise the number of times we look up the current thread,  
> while ensuring that we never leak memory.

On every platform platfrom that uses ELF, and on Windows, we can use  
thread-local static storage (__thread in the declaration).  This is  
very cheap (just an indirect lookup via the thread register) and as  
long as we remember to deallocate the NSZone in NSThread's destructor  
we won't leak.

Another option might be to extend NSAutoreleasePool to integrate an  
allocator.  This is actually a very nice idea, since it gives us a  
simple means of building generational garbage collection (each object  
could allocate itself by sending a message to the NSAutoreleasePool on  
the top of the stack, which could then promote objects into the longer  
running generation (parent pool on the stack) or delete them when it  
was destroyed.  This is a much bigger project though, and not one I'll  
be able to look at for a few months (although I'd like to eventually,  
since it seems a better solution to add allocation to  
NSAutoreleasePool and loop detection to NSObject than the horrible  
hacks that Apple have used to wedge GC into Objective-C 2.0).

David