[Top][All Lists]

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

Re: [Gnustep-cvs] r26723 - in /libs/base/trunk: ChangeLog Headers/Additi

From: David Chisnall
Subject: Re: [Gnustep-cvs] r26723 - in /libs/base/trunk: ChangeLog Headers/Additions/GNUstepBase/ Source/GSFFIInvocation.m configure
Date: Mon, 30 Jun 2008 15:09:57 +0100

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).


reply via email to

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