GC, memory leaks and 32/64 bit

[Rainer Schuetze]

On 13.03.2013 06:46, Druzhinin Alexandr wrote:
> On 12.03.2013 20:23, Benjamin Thaut wrote:
>> Am 12.03.2013 14:07, schrieb bearophile:
>>> Alexandr Druzhinin:
>>>
>>>> 32 bit versions (using dmd and gdc, win7/ubuntu 12.04) of my
>>>> application always leak very fast. But 64 bit version (ubuntu 12.04
>>>> only, win7 segfaults) works stable without any leaks. I'm curious is
>>>> there some workaround or I have to wait for GC improvement to build
>>>> 32bit version, without choice?
>>>
>>> This difference is caused by the difference in pointer space size
>>> coupled with the nature of a conservative GC.
>>> The "workarounds" are not easy, like allocating your largest arrays from
>>> the C heap.
>>> The past Summer Of Code was worked on a much more precise GC (but not
>>> fully precise) meant to reduce this problem a lot on 32 bit systems, but
>>> nothing solid has so far come out of that. It probably needs to be
>>> polished, tested, etc.
>>>
>>> Bye,
>>> bearophile
>>
>> Thats not correct. Rainer Schuetze has finished it and is using it for
>> VisualD. You can get a version of druntime which the percise GC from his
>> github branch https://github.com/rainers/dmd
>>
>> Kind Regards
>> Benjamin Thaut
> I tried to build dmd 2.062 + Rainer's druntime + phobos 2.062 + some
> code manipulation to make it compiles but I got undefined symbols (BTW
> may I link it with druntime 2.062 (besides Rainer's one) to get these
> symbols?).
> I guess it would be better to use 2.061 but my application doesn't
> compile with it now, will try it later. And it would be very nice to
> have some instructions about using alternative gc.

If the undefined symbols happen to be related to AssociativeArray, my 
current workaround is to add "alias Associative!(Key,Value) 
_workaround;" somewhere to force instantiation for the respective Key 
and Value types.

The precise GC needs some type info for the allocated memory, so I have 
added a TypeInfo parameter to most calls into the GC. This changes the 
interface, so the precise cannot be plugged into the current proxy 
implementation.

I'm currently cleaning up the precise GC implementation so it can be 
switched on with a version when compiling druntime. Here is the current 
state: https://github.com/rainers/druntime/tree/gcx_precise