On Tuesday, 30 September 2014 at 12:02:10 UTC, Johannes Pfau
wrote:
That's possible but insanely dangerous in case you forget to
reset the
thread allocator. Also storing stack pointers in global state
(even
thread-local) is dangerous, for example interaction with fibers
could
lead to bugs, etc. (What if I set the allocator to a stack
allocator
and call a function which yields from a Fiber?).
You also loose all possibilities to use 'scope' or a similar
mechanism
to prevent escaping a stack pointer.
Yes, I agree. One option would be to have thread-local region
allocator that can only be used for "scoped" allocation. That is,
only for allocations that are not assigned to globals or can get
stuck in fibers and that are returned to the calling function.
That way the context can free the region when done and you can
get away with little allocation overhead if used prudently.
I also don't agree with the sentiment that allocation/management
can be kept fully separate. If you have a region allocator that
is refcounted it most certainly is interrelated with a fairly
tight coupling.
Also the idea exposed in this thread that release()/retain() is
purely arithmetic and can be optimized as such is quite wrong.
retain() is conceptually a locking construct on a memory region
that prevents reuse. I've made a case for TSX, but one can
probably come up with other multi-threaded examples.
These hacks are not making D more attractive to people who find
C++ lacking in elegance.
Actually, creating a phobos light with nothrow, nogc, a light
runtime and basic building blocks such as intrinsics to build
your own RC with compiler support sounds like a more interesting
option.
I am really not interested in library provided allocators or RC.
If I am not going to use malloc/GC then I want to write my own
and have dedicated allocators for the most common objects.
I think it is quite reasonable that people who want to take the
difficult road of not using GC at all also have to do some extra
work, but provide a clean slate to work from!
