Migrating an existing more modern GC to D's gc.d

David Bennett davidbennett at bravevision.com
Thu Apr 12 07:23:00 UTC 2018


On Wednesday, 11 April 2018 at 19:38:59 UTC, Dmitry Olshansky 
wrote:
> On Tuesday, 10 April 2018 at 07:22:14 UTC, David Bennett wrote:
>> People cast from thread local to shared? ...okay thats no 
>> fun...  :(
>>
>> I can understand the other way, thats why i was leaning on the 
>> conservative side and putting more stuff in the global pools.
>
> Well you might want to build something as thread-local and then 
> publish as shared.

Yeah I can see if your trying to share types like classes, shared 
would get in the way quite quick.

> I think it could be __to_shared(ptr, length) to let GC know 
> that block should be added to global set of sorts. That will 
> foobar the GC design quite a bit but to have per thread GCs I’d 
> take that risk.

Yeah I had this idea also, the runtime gets a hook on 
cast(shared) and the GC then just sets a flag and that part of 
memory will never be freed inside a thread-local mark/sweep. No 
move needed.

> But then keeping in mind transitive nature of shared.... Maybe 
> not ;)

Yeah shared is quite locked down so should have less ways people 
could foil my plans.

It's __gshared that im worried about now, ie if you had a class 
(stored in global pool) that you then assigned a local class to 
one of it's members. When a thread-local mark/sweep happened it 
wouldn't see the ref in the global pool and the member might get 
removed...

---
class A{}

class B{
     __gshared A a;
     this(A a){
         this.a=a;
     }
}

void main()
{
     A a = new A();
     B b = new B(a);
}
---

Currently my idea of storing classes with __gshared members would 
put B on the global poll but theres no cast so A would not be 
hoocked with __to_shared(). I guess the compiler could in theory 
inject the same __to_shared() in this case also, but it would be 
a lot harder and would probably be a mess as theres no cast to 
hook.

So maybe with __gshared it should be on the thread-local pool but 
marked as global.. but you might be able to mix shared and 
__gshared in a way that wouldn't work.

> Maybe it should work the other way around - keep all in global 
> pool, and have per-thread ref-sets of some form. Tricky anyway.

Would be worth some thought, I'll keep it in mind.

For now, I'm seeing if I can just make it so each thread has it's 
own Bin list, this way the data is stored in a way where the 
thread-local stuff is generally packed closer together and theres 
a higher chance to have a whole free page after a global 
mark/sweep.

If there a good benchmark for the GC I can run to see if I'm 
actually improving things?


More information about the Digitalmars-d mailing list