Project Highlight: Spasm

[Radu]

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.