On 16-04-2012 20:02, Sean Kelly wrote:
On Apr 16, 2012, at 2:25 AM, Walter Bright wrote:
On 4/16/2012 2:05 AM, deadalnix wrote:
Having this template into object.d seems problematic to me. It is now quite hard
to provide any custom GC implementation without messing with Druntime.
Providing a user created GC should be as easy as possible.
It's never going to be easy for anyone to just write their own GC, especially
one that works better than one a lot of people have spent a lot of time on.
What I've been going for is to have all functionality that requires knowledge of code
generation, (most) platform specifics, etc, live in the compiler runtime portion of
Druntime (i.e. in the "rt" package). This is all stuff that the compiler
writer knows by necessity, and the GC writer shouldn't be required to know it as well.
As for pointer maps, I think it's reasonable to establish a format that these
will be made available to the GC, and for them to come from elsewhere in the
runtime. I realize that different GC implementations may prefer different
formats, but hopefully we can settle on one that's pretty generally usable and
efficient. I'd really rather avoid expecting GC writers to know how to
meta-process D types to statically generate this themselves. Moving this into
the GC would also eliminate the possibility of having the GC chosen at
link-time, which is something that's currently still an option.
I think we can safely settle on bitmaps for this. Most real world GCs
use this kind of strategy.
I think this is again solving an implementation issue by a language design
decision. Ultimately the useless code bloat must be handled by the toolchain
anyway.
We gotta work with what we have.
6. I suggest the GCInfo pointer be stored at the end of the allocated
block, as then it won't affect the alignment of the allocated data.
This very swap unfriendly. Many pages will have to be unswapped/swapped back in
the marking process, even if it is 100% useless for data that doesn't contains
pointers.
I think there's a misunderstanding. The GC allocates by powers of 2. So a 22
byte struct will be allocated in a 32 byte block, and the GCInfo pointer can go
at the end of that. That will not cause swapping.
As for data that has no pointers, something has to indicate that. Of course,
another strategy is to allocate such data in separate pools. In fact, that
might be an excellent idea, as such pools would never have to be read (i.e.
swapped in, loaded into cache) during the mark/sweep process.
This is obviously all for the current GC anyway. Another implementation may be
better off storing things elsewhere.
--
- Alex
