[fpc-devel] Boehm garbage collector for freepascal
thaddy at thaddy.com
Thu Nov 18 08:05:49 CET 2010
On 17-11-2010 10:01, Michael Schnell wrote:
> On 11/15/2010 02:04 PM, Thaddy wrote: ...
> If you want to extend a compiler to allow for garbage collection,
> would it not be appropriate to have it manage an additional type of
> variables that is supposed to be "garbage collection enabled"
> pointers and have it always create double indirect accesses to this
> type of variables. The "garbage collection enabled memory allocator"
> would manage a list of these variables and see that the value of the
> pointer is an entry in this list that again is a pointer to the
> instance. Now that garbage collector can do it's work without the user
> program knowing about this. t3
Well, basically, all these things have already been answered by the way
the Boehm GC's architecture has evolved. Threading is possible (Thread
local (sub) allocator/collector), you can mark memory as not GC'd etc.
The Boehm GC is a very mature piece of software engineering, that's why
f.e. it's the default for mono and the GNU static - not the bytecode -
java compiler. Note the static: this paradigm is very close in
implementation because this also assumes heap allocated objects etc.
In general, I have read nothing new that isn't already taken care of.
The implementation is pretty straight forward.
Reading the documentation and historical conversations is another thing
As it stands, my version as presented is not thread safe, though a
simple recompile BoehmGC with treading enabled is enough. The Freepascal
interface does not change.
There is even a mechanism in the Boehm GC that allows to recognize what
kind of memory is requested, by registering the type of an object, not
the object itself, to the collector.
This is extensively used in the static java compiler f.e. and thoroughly
Also: a GC is not as reliable for for example real-time applications
where indeed the GC can interfear, but there are calls to delay
collection and to perform the collection immediately.
Modern measurements show - and most in the know agree - that in
applications with many small allocations a GC may be faster, more
performant, than classic alloc/free.
There is a performance penalty only with large allocations (at least
under windows, I386) with blocks of 100K+ but you can always allocate
this manually if it becomes a problem.
And in the standard Delphi memory manager these big allocations are also
deferred to OS calls (virtual alloc family of win32 calls)
Boehm GC is not slow, on the contrary: the fact that it is conservative
makes it faster. More specific in real applications (specially server
applications, database handling etc) it may be faster, at the expense of
memory resources, but that is a given for many a speed-up anyway..
Boehm GC can be compiled for thread safety very simply (1 compile switch).
To summarize: what you write/propose is already in there :)
I have rather good initial results with it, even compiling medium/large
Freepascal projects with it, f.e. fpGUI and fpGUI designer ;-) :-)
I never proposed to make the GC mm the default, though. But it might be
an advantage for some projects as the discussions over the years implied.
When you carefully read the historical trail you realize most of the
arguments here are really old school and already falsified by the Boehm
community (except for stack based object allocations that is!)
More information about the fpc-devel