The terms "system level programming" and "garbage collection" are
mutually exclusive, but I see the value in GC. However, I cannot
really come up with a single situation where I don't know what
kind of allocator I have used when accessing a pointer.
I think it makes a lot of sense to think in the direction of the
post of Etienne and have allocator based pointer types. With a
template heavy coding style it becomes less problematic than in a
language like C. If you go templates all the way. That could
reduce the amount of scanned memory significantly. Basically I
think a system level language should have at least
owned/borrowed, ref counted and gc-pointer types.
I also wonder how often you actually have a need to discriminate
between more than 255 classes. It seems to me that with whole
program compilation you could often just use a single byte for
type info and a switch table for virtual functions. That would
leave a lot more room for optimization.
When it comes to allocators I am more likely to use a factory for
creating objects from my own allocator than pooling different
types in a generic allocator. Except maybe for regions that are
to be released at once, but I don't use that much. So I wonder if
it is better to rather spend the effort on partial
pre-initialization as an optimization for class specific
factories than trying to be overly generic. By partial
pre-initialization I mean that you reset used fields when an
object is freed, thus you don't need to reinitialize vtable
pointers and avoid calling constructors upon allocation (the
objects are pre-constructed). Ideally you push object
construction to time periods where the CPU is idle.
With a performance mindset…
