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