Different Memory Allocation Strategies in D - DConf Keynote

KnightMare black80 at bk.ru
Wed Jun 5 15:07:59 UTC 2019


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


More information about the Digitalmars-d-announce mailing list