On 2013-10-14 23:45:42 +0000, "deadalnix" <deadal...@gmail.com> said:
On Monday, 14 October 2013 at 21:25:29 UTC, Michel Fortin wrote:
I'm not an expert in GCs, but as far as I know a concurrent GC also
requires some bookkeeping to be done when assigning to pointers,
similar to ARC, and also when moving pointers, unlike ARC. So it
requires hooks in the codegen that will perform atomic operations, just
like ARC.
Usual strategy include :
- When you JIT, change the function itself, to write pointers through
a function that mark the old value as live.
- When AOT, always go throw that function, which make a test and mark
alive the old value if this is done during a collection. This basically
add a read to a global and a test for each pointer write.
- Use the page protection mechanism and do regular write. This can be
done via fork, but also via remapping the GCed memory as COW. The tax
is then more expensive, but you only pay it once per page you actually
write and only when actually collecting.
The good news, is that this tax is only required for object that
contains shared mutable pointers. In D, most data are thread local or
immutable. D's type system is really friendly to concurrent GC, and we
definitively should go in that direction.
The only consensus we'll reach is that different projects have
different needs. In theory being able to swap the GC for something else
could bring everyone together. But to be able to replace the GC for
another with a strategy different enough to matter (concurrent GC or
ARC) you need the codegen to be different. So we can either:
ARC like system need a different codegen, but you can do this with
regular codegen if you use page protection to detect writes.
Very insightful. Thank you.
1. make the codegen configurable -- which brings its own set of
compatibility problems for compiled code but is good for
experimentation, or
Bad, we will end up having different incompatible binaries.
So as I understand it, your plan would then be:
- use concurrent GC using the page protection mechanism and COW to
catch writes during collection
- add thread-local awareness to the GC so only shared and mutable
memory needs COW
Makes sense. But adding thread-local awareness requires a couple of
language changes. It won't work as long as people keep casting things
around so you need to fix a lot of cases where casts are needed.
But otherwise, seems like a good plan.
I'm a little wary of the cost of doing COW during collection. Obviously
the GC isn't pausing the program per-see, but it'll be slowing it down.
By how much is probably dependent on what you're doing. At the very
least the GC should allocate types with no pointers on separate pages
from those with pointers.
Also, what are the calls required to implement page protection and COW
on posix? I'd like to check whether those are allowed within the OS X
and iOS sandbox. For instance fork() isn't allowed for sandboxed apps.
--
Michel Fortin
michel.for...@michelf.ca
http://michelf.ca
