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?

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

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

Ah sorry, I meant to post: https://github.com/rainers/druntime/tree/precise_gc2

Kind Regards
Benjamin Thaut

Benjamin Thaut:

> 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

I am glad to be wrong :-)

Do you know how well the new GC is working?

Bye,
bearophile

On Tuesday, 12 March 2013 at 14:21:06 UTC, bearophile wrote:
> Benjamin Thaut:
>
>> 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
>
> I am glad to be wrong :-)
>
> Do you know how well the new GC is working?

Haven't sociomatic (Don) used it in production a while too? I think I remember reading something on that, and that it was working good.

Am 12.03.2013 15:21, schrieb bearophile:
> Benjamin Thaut:
>
>> 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
>
> I am glad to be wrong :-)
>
> Do you know how well the new GC is working?
>
> Bye,
> bearophile

Rainer stated that it works just fine, but in its current state it is slower then the impercicse GC.

Kind Regards
Benjamin Thaut

On Tuesday, 12 March 2013 at 14:21:06 UTC, bearophile wrote:
> Benjamin Thaut:
>
>> 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
>
> I am glad to be wrong :-)
>
> Do you know how well the new GC is working?
>
> Bye,
> bearophile

It should be a plugin so that components like an alternate GC can be swapped in and out easily. I hope once shared lib support becomes available we'll finally see plugins introduced into dmd.

--rt

Am Tue, 12 Mar 2013 21:08:01 +0100
schrieb "Rob T" <alanb@ucora.com>:

> It should be a plugin so that components like an alternate GC can be swapped in and out easily. I hope once shared lib support becomes available we'll finally see plugins introduced into dmd.
> 
> --rt

Well, you can already today set a proxy for the GC. This
mainly to disable a DLLs GC and make it foward everything to
the main executable's GC, but you can use for other purposes.
It just means an additional indirect function call for every
GC method call.
An alternative is to override all of the exported GC C
functions with your own implementations, so that the linker
will prefer the versions found in your code rather than the
ones in Phobos. But this doesn't allow swapping at runtime.

-- 
Marco

On Tuesday, 12 March 2013 at 20:29:58 UTC, Marco Leise wrote:
> Am Tue, 12 Mar 2013 21:08:01 +0100
> schrieb "Rob T" <alanb@ucora.com>:
>
>> It should be a plugin so that components like an alternate GC can be swapped in and out easily. I hope once shared lib support becomes available we'll finally see plugins introduced into dmd.
>> 
>> --rt
>
> Well, you can already today set a proxy for the GC. This
> mainly to disable a DLLs GC and make it foward everything to
> the main executable's GC, but you can use for other purposes.
> It just means an additional indirect function call for every
> GC method call.
> An alternative is to override all of the exported GC C
> functions with your own implementations, so that the linker
> will prefer the versions found in your code rather than the
> ones in Phobos. But this doesn't allow swapping at runtime.

I don't think you'd want to swap a GC during runtime anyway, but who knows, so having that ability is probably better than not having it.

Do you know if there are instructions posted somewhere on how to override or proxy the GC?

--rt