https://www.reddit.com/r/programming/comments/bwz91d/different_memory_allocation_strategies_in_d/

On Wednesday, 5 June 2019 at 06:34:10 UTC, Walter Bright wrote:
> https://www.reddit.com/r/programming/comments/bwz91d/different_memory_allocation_strategies_in_d/

about RC at 30:40:
I dont understand why thrown exception do expensive RC with catch-decrement-rethrow? destructors are called in unwinding state where exception is catched once with suitable handler, isnt it?

On Wednesday, 5 June 2019 at 06:34:10 UTC, Walter Bright wrote:
> https://www.reddit.com/r/programming/comments/bwz91d/different_memory_allocation_strategies_in_d/

thoughts about RC at 27:14 (talk for x64 only: AARCH64, X86_64..)
and people do some work already at GSoC so my 2 cents

1) I saw 2 ptrs in video for data and RC. imo better store (for containers at least)
                         data_begining_ptr
                             |
                             v
[IAllocator_ptr][RC][length][datas| | | | | | | ]
most like BSTR in Windows with added IAlloc.ptr for different areas.

when we have raw data-ptr we can get ptr to IAllocator and free it:
((IAllocator*)(((byte*)data_ptr)-RC.sizeof-length.sizeof-IAllocPtr.sizeof))->free( data_ptr )
when RC==0.

what about TypeInfo at metadata block? dunno

2) occupied memory for metadata (RC,IAlloc,length): RC and IAlloc can take less then 64bits as Apple do with ARC. and x64_64 uses only 48bits for addressing memory (ARM probably less). IAlloc can be not ptr to IAllocator but index in global IAllocator array (as singletons).

3) strategies for RC-counter itself should exists: atomic or not, x64 or x32 or XXbits, and some another counter types maybe.

4) template containers can store fundamental types and structs with no refs (I dont consider hacks with storing refs-to-somewhat as ulong. imo CTFE can check user types). so we can cover ~80% of using nonGC types - sure no classes no struct-with-refs. like Kotlin intArray, doubleArray, Array!UserTypeWoRefs

5) for wo/refs types containers we can code/use slices Span(T) { dataPtr, index0, length; } that can handle RC too. I dont think about immutability yet. Span must to know that this containers store RC at known place to work with him. What about different types of RC? well Span(T,RC)

6) or RCounter stores allocatorPtr inside itself? when RC==0 it free block through allocator (or gloabl alloc/free) without external supervisor. dunno