[dmd-internals] Giving better static data limits to the GC

[Jason House]

Last time I read about the GC work, I had the impression that each allocation would store an extra int/pointer regardless of how small it was. I remember something like a 20% increase in memory footprint.

You raise a good point though. There's no need to use pointers to typeinfo or object-specific bit masks. An allocated block has a deterministic scanning pattern until it is collected. The memory footprint could be as efficient as the free memory block bits that are already in the GC. 

Sent from my iPhone

On Aug 23, 2010, at 8:40 AM, Steve Schveighoffer <schveiguy at yahoo.com> wrote:

> There is TypeInfo generated for structs too.  Why couldn't you store the bits 
> for that type in that typeinfo?
> 
> The only issue I see is the overhead in storing a pointer to typeinfo for a 
> small block (i.e. a 16-byte block adds 4 bytes of overhead to store at most 4 
> bits of pointer info).  For small blocks, you could store the bitmask with the 
> block instead of a pointer to the bitmask.
> 
> -Steve
> 
> 
> 
> ----- Original Message ----
>> From: Jason House <jason.james.house at gmail.com>
>> 
>> My understanding is that classes can have scanning data in their type info, but  
>> everything else (structs, etc) need to have scan info stored with the object. It  
>> would be interesting if the dynamic allocations were segmented into scan and no  
>> scan memory areas similar to what was suggested for static data.
>> 
>> Sent  from my iPhone
>> 
>> On Aug 23, 2010, at 7:19 AM, Steve Schveighoffer <schveiguy at yahoo.com> wrote:
>> 
>>> From what I understand, that was what the original precise scanning patch  
>> did.  
>> 
>>> Since the tables are static, having the compiler do it is a  better idea.
>>> 
>>> But I think the "large footprint" might be  somewhat of a strawman.  Yes, it 
>> will 
>> 
>>> increase space, but I don't  think it will be that much.  Consider that the 
>>> precise scanning  bits are static, and will be stored statically.  Have we 
>> run 
>> 
>>> any  tests to see how much space it actually adds?
>>> 
>>> -Steve
> 
> 
> 
> 
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals