GC conservatism -- again

Vladimir Panteleev vladimir at thecybershadow.net
Wed Dec 29 07:00:52 PST 2010


On Wed, 29 Dec 2010 16:28:03 +0200, Steven Schveighoffer  
<schveiguy at yahoo.com> wrote:

> On Wed, 29 Dec 2010 01:00:01 -0500, Vladimir Panteleev  
> <vladimir at thecybershadow.net> wrote:
>
>> On Wed, 29 Dec 2010 05:13:10 +0200, Vladimir Panteleev  
>> <vladimir at thecybershadow.net> wrote:
>>
>>> when the total size of pointers in the managed heap
>>
>> Correction: total size of *stray* pointers. This is a very important  
>> distinction. If you have over 300 MB of stray pointers in your managed  
>> heap, then it's almost certain that some binary data is being marked as  
>> having pointers. Common culprits are void[] allocations, and large  
>> structs/classes that mix pointers and non-pointers.
>
> This is cool stuff.  This is what I normally was considering to be the  
> problem with conservative GC.  However, I discovered that the reverse  
> relationship also causes problems -- if you have a large block *not*  
> containing pointers (say, a char[]), the chances that some 4-byte part  
> of a pointer-containing struct "points" to it is relatively high as  
> well.  The probability of a random integer pointing to a 200MB block is  
> 1/20 (logically, 200MB is 1/20 of 2^32).  I think this might be a worse  
> problem than the unlikely scenario that you allocate 200 or 300 MB of  
> void[] data, since that isn't very common.  Essentially, you have no  
> recourse but to manually manage that memory, there isn't a magic bullet  
> (such as reallocating as ubyte[]).
>
> Especially when it is frowned upon to forcefully deallocate memory...
>
> -Steve

Yes, this was the main motivation behind my data.d module :) If you need  
to manage large blocks of plain data, the simplest solution at the moment  
is not to keep it in the managed heap.

-- 
Best regards,
  Vladimir                            mailto:vladimir at thecybershadow.net


More information about the Digitalmars-d mailing list