System level language, GC, allocation and typeinfo

via Digitalmars-d digitalmars-d at puremagic.com
Tue May 27 06:06:09 PDT 2014


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…


More information about the Digitalmars-d mailing list