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

[Steve Schveighoffer]

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