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

Steve Schveighoffer schveiguy at yahoo.com
Mon Aug 23 05:40:11 PDT 2010


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



      


More information about the dmd-internals mailing list