On Tuesday, 18 November 2014 at 20:34:01 UTC, Ola Fosheim Grøstad wrote:
Does this mean that you need all threads (which I presume are the mutators) to be in an eventloop in order to collect?
What you need is for each thread to provide you a list of roots. You can start tracing while having an incomplete list of roots, so the level of concurrency allowed is high. As for the immutability thing, here is how it goes. When you compile to native, you can either do write barrier all the time, via writing point using a function call in the runtime. The second option is to not do it and use memory protection to trap write. Option 1 is usually preferred by VM that can swicth implementation of methods when collecting, so you pay a moderate cost and only when you collect. But if you compile AOT, you always pay that price and it is not very interesting. Optin 2 is WAY more expensive and will trap even write to value, not only pointers. If it expensive, it is only expensive when it traps. That mean it is a very interesting choice for code compiled ahead of time and manipulating immutable data. This is very interesting in the case of ML, where the compiler sometime choses to mutate, but only as an optimization, and very rarely on object that reach the big heap, as if the object is long lived enough to reach that heap, most likely the compiler can't prove it is unique and thus mutable. The same strategy seems like the obvious winner for D's immutable heap as well as part of the shared heap that do not contain mutable pointers.