On Thursday, 23 January 2014 at 22:39:38 UTC, Vladimir Panteleev
wrote:
I believe the biggest factor for why someone would want to use
a lighter runtime is the garbage collector. I think a lot of
the code in Druntime still assumes that a GC is present... and
then I'm not sure the D maintainers would want to maintain
support for such rarely-needed features such as a custom entry
point. (Case in point: pragma(entrypoint, symbol) has been
broken since DMD 2.061.)
The GC seems to be the biggest issue here, so I wanted to comment
separately.
Each target/platform/application will have different requirements
and those requirements will dictate the type of memory management
implementation to use.
Ideally, I don't see why D has to be a garbage collected
language. Can't it be agnostic to the memory management
implementation?
D seems to offer several options to the programmer, Scoped,
RefCounted, new/destroy, and can even create their own garbage
collection with the gcstub (or so I've heard). This is great!,
but it's not idea as it forces the programmer to change their
idioms. It appears that D is very tightly coupled to the memory
management implementation, but does it need to be?
Couldn't the runtime provide some hooks that can be used by the
runtime implementation to know when a class is instantiated, when
it goes out of scope, when it's assigned to another reference,
etc... and use this to provide a variety of different memory
management implementations without the programmer having to
change their idioms? I'm hypothesizing that if these runtime
hooks existed, one could create a transparent reference-counted
implementation that would be mostly transparent to the
programmer, for example. I still think the programmer will have
to write code with their memory management implementation in
mind, but they could at least stick to the same idioms.
I'm not very optimistic, but I'm hoping something like this can
be achieved, and that's what I'm shooting for. Absent this
possibility, I'm not sure what to do.
I believe there is probably a GC implementation that would be
suitable for a my target platform (ARM Cortex-M
microcontrollers). I can think of at least one: Some firmware
for microcontrollers simply need to allocate all of their objects
at the start of the program, but have no need to free memory:
free is the power switch. For applications like this only
gc.allocate() needs to be implemented, and the GC's background
thread and gc.free() do not. I think this would allow the
programmer to stick with traditional D idioms, but they have to
keep in mind gc.free() will never be and should never be called.
Some compile-time guarantee here would be nice.
I could go on and on about some of my ideas, but I think I've
said enough for now. I've got a lot to learn first, anyway.
Mike
