On Thursday, 28 February 2019 at 20:36:57 UTC, Sebastiaan Koppe
wrote:
On Thursday, 28 February 2019 at 12:47:32 UTC, Radu wrote:
Re. the memory management section, I wonder if reference
counting using dip1000 would work for memory management.
At least partly. One memory issue spasm has is to release JS
objects once D code is done with them. The approach I am likely
to take is to simply disallow more than 1 reference to a JS
object, and then when that reference is destroyed, to also
destroy the JS object. Basically a non-copyable struct with a
destructor.
Over time this can be expanded with dip1000 to allow having
more references to the same JS object as long as the compiler
can prove it doesn't escape and has shorter lifetime.
I don't see how dip1000 can help free memory though.
You could also use the type system information for a D malloc
implementation that uses free lists for known sizes. Something
in line with https://github.com/JinShil/memcpyD
I saw memcpyD before. In fact I used part of the implementation
in a (uncompleted) wasm port of druntime.
But again, I don't see how it would help with freeing unused
objects.
It is quite interesting to see that WebAssembly lines up
pretty close to bare metal programming, maybe there are some
synergies here that can be exploited and create the minimum
runtimes for both.
Definitely.
Dip1000 would make reference counting safe.
Memory management should be handled by reference counting. RC
should delegate malloc, free to an allocator.
Hence my suggestion to implement a typed malloc. Probably an
allocator and memcpy friends that works in betterc without any C
dependencies would worth its own dub package :)
The complexity of the allocator and ref counting is drastically
reduced as there is no multithreading involved.