[D-runtime] GC expectations from TLS?

[Steve Schveighoffer]

My plan is for the GC collection cycle to purge memory locations that have been 
collected from the caches.  I obviously have to do this with the world stopped, 
I was thinking of doing it from within the signal handler for each thread, since 
each natively has access to its TLS.  Otherwise, I need a way to get at TLS of 
other threads.  Actually, that might be better if it's possible because I don't 
have to worry about synchronizing those threads with the collecting one...

Does this make sense?

One thing I haven't yet looked at -- how to determine if a part of memory is 
'collected'.  I haven't looked at the details, but I'm assuming that in between 
mark and sweep (and consequently when the world is about to be unstopped), I can 
determine if a piece of memory is about to be collected easily given the 
BlkInfo, or do I need to store an additional pointer to the metadata structure 
for that piece of memory?

This needs to be handled very delicately, and I've pretty much put it off 
because I'm scared of breaking things horribly :)  I already experienced how bad 
of problems I can cause by my last foray into the GC (original appending patch).

-Steve



----- Original Message ----
> From: Fawzi Mohamed <fawzi at gmx.ch>
> To: D's runtime library developers list <d-runtime at puremagic.com>
> Sent: Sat, November 13, 2010 4:37:33 PM
> Subject: Re: [D-runtime] GC expectations from TLS?
> 
> thinking more about it one has to ensure that allocation at the same place as a  
>previously grown array sets the cache (or purges the old value).
> 
> On  13-nov-10, at 10:37, Fawzi Mohamed wrote:
> 
> > having a real weak pointer  is not easy and has a cost because there is a 
>hole between marking an object as  collected and calling its dtor (that array 
>don't even have by default).
> > 
> > But in your case you will never dereference an object that might have  been 
>collected, so it is easier.
> > 
> > Probably the easiest way to  have what you want is to use a struct that keeps 
>the prt as non aligned size_t  value (just (arr.ptr | 1) and remove that bit 
>when needed, the scanning should  ignore the non aligned value, and you are 
>ok...
> > 
> > On 13-nov-10,  at 00:26, Steven Schveighoffer wrote:
> > 
> >> Static  ctor/dtor?
> >> 
> >> Sent from my iPhone
> >> 
> >>  On Nov 12, 2010, at 5:56 PM, Sean Kelly <sean at invisibleduck.org>  wrote:
> >> 
> >>> On Nov 12, 2010, at 12:25 PM, Steve  Schveighoffer wrote:
> >>>> 
> >>>> I would like to  avoid a heap allocation (which I know will work) on every  
>thread
> >>>> creation, but it's looking to me like this is what's  going to have to 
>happen.  I
> >>>> probably can use malloc to  avoid it being scanned.  Is there another 
way?
> >>> 
> >>> I don't think there is.  The TLS block is static memory,  so there's no way 
>to flag it as not containing pointers.  You'll need some  way of being notified 
>when the block is collected too.
> >>>  _______________________________________________
> >>> D-runtime  mailing list
> >>> D-runtime at puremagic.com
> >>> http://lists.puremagic.com/mailman/listinfo/d-runtime
> >>  _______________________________________________
> >> D-runtime mailing  list
> >> D-runtime at puremagic.com
> >> http://lists.puremagic.com/mailman/listinfo/d-runtime
> > 
> >  _______________________________________________
> > D-runtime mailing  list
> > D-runtime at puremagic.com
> > http://lists.puremagic.com/mailman/listinfo/d-runtime
> 
> _______________________________________________
> D-runtime  mailing list
> D-runtime at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/d-runtime
>