[fpc-devel] limited -gc ?

Thaddy thaddy at thaddy.com
Mon Oct 10 14:12:55 CEST 2011


On 9-10-2011 22:34, Martin wrote:
> -gc, is apparently only useful in very limited scenarios, such as 
> applications, that have no interaction with the OS at all, or can 
> otherwise gurantee, never to access any memory that was returned by 
> (and therefore allocated by) the OS.
>
No, it only means allocation should be done in a dedicated memory 
manager that registers classes and dynarrays (or any) for GC.
I already did that with my Boehm implementation (based on another one by 
Barry Kelly that also did do just that and I borrowed most of the idea's 
from) but for some reason people on this forum think this is too slow. 
It isn't.
(RTM, P!)
I have it running in many a production scenario for at least 4 years 
(big ones)
My Boehm GC version is actively maintained, so try that one.

> An LCL app can not guarantee that...
>
> Yet what I am looking for is a simpler variant, that can help doing 
> the same for class-instances, or dyn-array.
>
See above.
> For classes there is -CR but it act only when calling methods (any 
> method or only virtual methods?), I can for example not tell if 
> accessing a property mapped to field would also trigger tests on this.
>
> Every class or dyn array should be in a block of memory allocated by 
> the fpc heap mgr (probably even always at the start (or fixed offset) 
> of such a block). Therefore I would guess (just guess...) that such a 
> check could be done?
Yes, easy.
> It would greatly help finding any access to freed data.
>
The Boehm GC has options (the registered memory is maintained and 
accessible)  for that during debugging, but not for production quality. 
That would defeat the point of a GC.




More information about the fpc-devel mailing list