[fpc-devel] Boehm garbage collector for freepascal

[Thaddy]

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

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

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

Thaddy