Andreas Raab writes:
Ralph Johnson wrote:
That is a very interesting plan, Andreas. However, I don't see garbage collection on the list. Won't you have to make a concurrent garbage collecter?
I don't think so. First, you don't need a new garbage collector for the direction that I would take. Since the threads don't operate on the same object memory, no change to the collector is needed. And for shared state concurrency, simple solutions (like a gc request flag per thread which is checked on each send) can be used to ensure atomic operation of the collector.
You'd need to serialise object creation and accessing the root table in the write barrier. That may be possible without too much work but there's likely to be some overhead.
Providing a parallel object memory as part of a garbage collector rewrite that speed up single CPU code should be possible. The major design change would be changing the write barrier from a remembered set to card marking. That unfortunately might make it necessary to separate pointer object space from byte storage space.
From the reading I did when tuning Exupery's memory access, it looks
like a mostly parallel old space collector should be about the same amount of work as writing an incremental collector. The trick is to only run the big mark phase and the big sweep phase in parallel with the interpreter then stop the interpreter to do the final marks.
That said, share nothing scales to multiple computers. If you really need CPU power it's often cheaper to buy many smaller boxes than a few big ones.
Bryce