Tasks, actors and garbage collection

[Ola Fosheim Grøstad]

As computer memory grows, naive scan and sweep garbage collection 
becomes more and more a burden.

Also, languages have not really come up with a satisfactory way 
to simplify multi-threaded programming, except to split the 
workload into many single-threaded tasks that are run in parallel.

It seems to me that the obvious way to retain the easy of use 
that garbage collection provides without impeding performance is 
to limit the memory to scan, and preferably do the scanning when 
nobody is using the memory.

The actor model seems to be a good fit. Or call it a task, if you 
wish. If each actor/task has it's own GC pool then there is less 
memory to scan, and you can do the scanning when the actor/task 
is waiting on I/O or scheduling. So you would get less intrusive 
scanning pauses. It would also fit well with async-await/futures.

Another benefit is that if an actor is deleted before it is 
scanned, then no scanning is necessary at all. It can simply be 
released (assuming destructor-free classes are allocated in a 
separate area). This is of great benefit to web-services, they 
can simply implement a request-handler as an actor/task.

The downside is that you need a non-GC mechanism for dealing with 
inter-actor/task communication. Such as reference counting, 
however that should be quite ok, as you would expect the 
time-consuming stuff to happen within an actor/task as well as 
complex allocation patterns.

Is this a direction D is able to move in or is a new language 
needed?