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?

Reply via email to