Garbage collector throwing during collection

[Daniel Gibson]

Am 16.07.2011 20:22, schrieb Sean Kelly:
> On Jul 14, 2011, at 7:21 AM, Robert Jacques wrote:
>
>> On Thu, 14 Jul 2011 08:39:06 -0400, Sean Kelly<sean at invisibleduck.org>  wrote:
>>
>>> On Jul 14, 2011, at 3:12 AM, Vladimir Panteleev wrote:
>>>
>>>> On Thu, 14 Jul 2011 09:58:09 +0300, Sönke Ludwig<ludwig at informatik.uni-luebeck.de>  wrote:
>>>>
>>>>> On DMD I got some strange out-of-memory errors with the current 2.054 version. I tracked it down to allocations happening during garbage collection.
>>>>>
>>>>> Has something fundamental in the GC implementation changed in the latest release? It used to work, but seems to be completely disallowed now. I think it is quite a strong requirement to not make any allocations from within finalizers and makes them just another bit more useless. (In my case I have some logging going on which needs dynamic allocations for formatting (Appender)).
>>>>
>>>> Hi, I was the one who submitted the patch. The situation before the patch was that allocating memory from a finalizer of a collected object inevitably lead to memory corruption (which is, as you may know, devilishly hard to track down). Ideally, someone would rewrite the appropriate parts of the GC to allow safe throwing and allocations from finalizers, but that hasn't happened yet.
>>>
>>> I started on the rewrite, but it's a pretty big change so I'm considering trying out Leandro's GC instead.  It would require some work as well, but the code is cleaner and it already supports precise scanning, so it may be a better starting point.
>>
>> IIRC Leandro's GC doesn't work on windows.
>
> If it doesn't then it shouldn't be too hard to fix.  Leandro intended it to work on Windows but didn't have a test box.

I'm not sure, but I seem to remember it uses fork()?
fork() is not available on Windows (there are workarounds, but they are 
slow, unlike the copy-on-update implementation of modern Unix like 
operating systems).

Cheers,
- Daniel