Memory Management in D: Request for Comment

[downs]

dsimcha wrote:
> == Quote from downs (default_357-line at yahoo.de)'s article
>> dsimcha wrote:
>>> == Quote from downs (default_357-line at yahoo.de)'s article
>>>> I submitted a patch a while back for constant-time removeRange. Can we dredge
>>> that one up and/or implement something similar? It's rather useful for things like
>>> stackthreads that need to add and remove lots of ranges :)
>>>> (Search the NG for "Feature req.+Patch: O(1) removeRange")
>>> I guess removeRange is currently O(N)?  I haven't looked.  Anyhow, I think the
>>> bigger problem in practice, i.e. until N is unrealistically large, is that
>>> removeRange requires taking a lock.  O(1) would be nice, though.
>>>
>>> What does StackThreads (I assume this is equivalent to fibers) do that it requires
>>> so many add/remove ranges?
>> The virtual stacks I use are being allocated via mmap. Every stack is a range.
> With every context switch, the relevant ranges need to be modified - the range
> that is being switched to needs to be removed (because it becomes the "main" stack
> which has special GC handling), and the stack range that's being switched from
> needs to be added.
> 
> IDK, that sounds a bit expensive even with O(1) removeRange.  Are you using some
> home-grown impl. of StackThreads/fibers, Tango's, or D2 druntime's?  If it's
> Tango's or druntime's, I haven't looked, but I would think the GC understands
> stuff about them.  If it's your own, have you considered switching and maybe
> submitting whatever extra features your impl. has to Tango and/or druntime?

Well .... D1 Phobos :)

I have some philosophical disagreements with the Tango project, much as I admit their technical superiority, and D2 is still too beta. But at least I don't use tools.stackthreads that much these days, so it's fine :)