On Sat, 07 Apr 2012 21:56:09 -0400, Walter Bright
<[email protected]> wrote:
Of course, many of us have been thinking about this for a looong time,
and what is the best way to go about it. The usual technique is for the
compiler to emit some sort of table for each TypeInfo giving the layout
of the object, i.e. where the pointers are.
The general problem with these is the table is non-trivial, as it will
require things like iterated data blocks, etc. It has to be compressed
to save space, and the gc then has to execute a fair amount of code to
decode it.
It also requires some significant work on the compiler end, leading of
course to complexity, rigidity, development bottlenecks, and the usual
bugs.
An alternative Andrei and I have been talking about is to put in the
TypeInfo a pointer to a function. That function will contain customized
code to mark the pointers in an instance of that type. That custom code
will be generated by a template defined by the library. All the compiler
has to do is stupidly instantiate the template for the type, and insert
an address to the generated function.
The compiler need know NOTHING about how the marking works.
Even better, as ctRegex has demonstrated, the custom generated code can
be very, very fast compared with a runtime table-driven approach. (The
slow part will be calling the function indirectly.)
And best of all, the design is pushed out of the compiler into the
library, so various schemes can be tried out without needing compiler
work.
I think this is an exciting idea, it will enable us to get a precise gc
by enabling people to work on it in parallel rather than serially
waiting for me.
I think this is a really good idea.
I would like to go further and propose that there be an arbitrary way to
add members to the TypeInfo types using templates. Not sure how it would
be implemented, but I don't see why this has to be specific to GCs. Some
way to signify "hey compiler, please initialize this member with template
X given the type being compiled".
This could be a huge bridge between compile-time and runtime type
information.
-Steve
