On Saturday, 30 August 2014 at 02:11:49 UTC, Dicebot wrote:
====================================
Jakob Ovrum
====================================
"The *API* must support minimal dynamic memory allocation for
the normal execution path. However, theoretical *implementation*
changes that reduce memory allocation are not a deal-breaker."
This seems to be addressed but though it is desired to verify
it via @nogc unittest block which uses stub no-op logger (to
verify that nothing in between allocates). One place were GC
allocations is unavoidable is core.d:1628 - it will always
create FileLogger first and allow assigning custom one later.
Is there any way to circumvent it?
Yes - split the `stdlog` property into a getter and a setter.
Then if the setter is called first (with a non-null reference),
the getter never gets to allocate the default instance. I pointed
this out in a line comment before, but I guess it disappeared due
to the name change...
Also, as I said in the line comment, it doesn't need to
GC-allocate, it can allocate in global memory or TLS using
emplace (which of them is appropriate depends on the threading
model, I guess...). If Andrei's reference-counting suggestion is
implemented, then depending on the details, it's possible that
the default logger could be allocated on the C heap instead of
the GC heap as well, managed by RC.
