So, in order to get the ball rolling on the new GC I intend to
implement for D, I want to facilitate a lively discussion of the
design of it, so that it can be designed to be both robust and
free of design flaws. To keep the discussion from getting
derailed, I want to lay out a few guidelines, but want to get
feedback on those guidelines before I actually implement them. My
current draft of them is as follows:
First we’ll start with a brief overview of the development
process:
A PR will be created for DMD, DRuntime, and, although it may stay
empty, Phobos. A new commit will be created for each update of
the implementation, this includes bug fixes, and continuing work
on the implementation, in as many iterations as are required.
This is done to allow progressive review of the code rather than
trying to review the PRs as a whole, because, as it is likely to
include several thousand lines of changes to the code, it would
be impractical to review all at once.
No force push should ever be done to the PRs except to fix a typo
in or clarify a detail of the commit message for the newest
commit. If there is a typo in a commit message, or it is not very
clear on what was actually done, and another commit has already
been pushed, the typo or un-clear message shall remain for all
eternity. The suggested remedy in this case is to make a note of
the typo or clarify the commit message with a comment on the
commit.
PRs to the PRs are welcome, it is however encouraged to
coordinate any work you do with the others actively working on
the GC. The primary outlet for this should be the IRC, however,
should the need arise, the mailing list is a valid venue for this.
Github should be used as the primary outlet for discussion of
actual code, due to the ease of referencing code, as well as the
ability to tell if a comment is about a piece of code that was
already changed.
The mailing list should be used exclusively for discussion of the
design. It should not be used for discussing snippets of code in
the actual implementation. It can, and should be, used to discuss
snippets of code that may demonstrate a flaw, weakness, or
strength in the design.
The IRC should be used for rapid-fire Q&A, or bringing someone
up-to-date with the discussion and progression of the GC so far.
Discussion about inconsistencies in the coding style of the
implementation (whitespaces, newlines, etc.) should reside
exclusively on the IRC, as they are things that a future reader
of the discussions doesn’t really care about. If a discussion of
the overall code style used in the implementation is required, a
thread should be created on the mailing list.
The IRC should not be used to facilitate a design discussion. The
reason for this is twofold, firstly the IRC has a limited
audience, thus limited feedback, and secondly, I want the
discussion of the design to stand as documentation for why the GC
is designed the way it is.
Now, on to the guidelines for the design discussion.
ARC does not exist. We are implementing a GC, however, if the
opportunity arises to allow an efficient implementation of
interfacing with an external ARC platform, such as what is used
in Objective C, discussion of that interfacing mechanism is
permitted.
If DMD support is needed, it exists. This means that if the GC
needs DMD to be capable of something such as scope analysis in
order to make a particular optimization, then DMD should be
assumed to be capable of doing that.
While language additions may be proposed, the design must still
be able to function should the additions not be done, as the
additions should only be to allow for additional optimization
opportunities. For instance, re-introducing scoped class locals.
After all of that, I intend to include a base draft of the design
of the GC, along with opening the PRs and committing the starting
API. So, is there something I’m missing? Am I overlooking the
obvious? Is there a more practical way to produce the same
results?
