On 2014-11-16 19:32, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> Does the allocated object belong to a global database, a thread local
> database or a fiber cache which is flushed automatically when moving to
> a new thread? Or is it an extension of the fiber statespace that should
> be transparent to threads?

I'm not sure what this means, wouldn't the fiber stacks be saved on the thread-local space when they yield? In turn, they become part of the thread-local stack space I guess.

Overall, I'd put all the GC allocations through malloc the same way it is right now. I don't see anything that needs to be done other than make multiple thread-local GC instances and remove the locks. I'm sure I'll find obstacles but I don't see them right now, do you know of any that I should look out for?

On Monday, 17 November 2014 at 00:44:13 UTC, Etienne Cimon wrote:
> I'm not sure what this means, wouldn't the fiber stacks be saved on the thread-local space when they yield? In turn, they become part of the thread-local stack space I guess.

If you want performant, low latency fibers you want load balancing, so they should not be affiliated with a thread but live in a pool.

That said, fibers aren't a low level construct like threads so I am not sure if they belong in system level programming anyway.

> Overall, I'd put all the GC allocations through malloc the same way it is right now. I don't see anything that needs to be done other than make multiple thread-local GC instances and remove the locks. I'm sure I'll find obstacles but I don't see them right now, do you know of any that I should look out for?

Not if you work hard to ensure referential integrity. I personally would find it more useful with an optional GC where the programmer takes responsibility for collecting when the situation is right. (specifying root pointers, stack etc).

I think the language should limit itself to generate the information that can enable precise collection, then leave the rest to the programmer…

Previous thread: http://forum.dlang.org/post/dnxgbumzenupviqymhrg@forum.dlang.org

On 2014-11-17 9:45 AM, Kagamin wrote:
> Previous thread:
> http://forum.dlang.org/post/dnxgbumzenupviqymhrg@forum.dlang.org

Looks somewhat similar but the idea of a shared GC will defeat the purpose and will end up complicating things. After another review of the problem, I've come up with some new observations:

- The shared data needs to be manually managed for a thread-local GC in order to scale with the number of CPU cores

- Anything instantiated as `new shared X` will have to proxy into a shared allocator interface or malloc.

- All __gshared instances containing mutable indirections will cause undefined behavior

- All thread-local instances moved through threads using cast(shared) and carrying indirections will cause undefined behavior

- Immutable object values must not be allocated on the GC and defined only in a shared static this constructor to ensure the values are available to all threads at all times

The only necessity is shared/non-shared type information during allocation and deallocation.

The __gshared and cast(shared) issues are certainly the most daunting. This is why this GC would have to be optional through a version(ThreadLocalGC)