Garbage collector for c++ version

[clinuxrulz]

@the-real-blackh

I've translated "Gc.rs" from Rust to C++ . It is designed to work exactly the same way as the rust one. It uses the template struct Trace to mimic a Trace trait.

https://github.com/clinuxrulz/gc-cxx

If this is the sort of approach you would like to use, then maybe it could find a home in "SodiumFRP/.." somewhere.

The strategy in mind for use is: WeakGc<> forward references, Gc<> back references. The back references tend to get held in the cleanup/finalizers of the sodium objects.
Trace implementations would need to be provided for Cell/Stream and Listener to use it. (I.E. Anywhere a Gc<> could be held needs to be made reachable by Trace<>::trace(...))

Here is what it looks like when you use it:
https://github.com/clinuxrulz/gc-cxx/blob/master/example.cpp

The example creates a cycle among 3 objects and shows them getting freed at the end of the local scope.

[the-real-blackh]

Thank you! You have just saved me a whole lot of work! I've really got to find some time to finish this off.

[clinuxrulz]

I've switched over std::shared_ptr to Gc<>, and std::weak_ptr to GcWeak<> in a fork of sodium-cxx.

I'm getting Seg Faults at the moment. However the gc.h and gc.cpp files are tiny, so it shouldn't take long to figure out the bugs.

[clinuxrulz]

I think I have a design mistake:
Say we have Gc<A> which has a cycle with other Gc<> objects. As deconstructor can end up re-rooting a Gc<> that has already been freed, and thus cause a segfault. I'll have to think about it for a while.

[ziriax]

In the old days when I was developing games, we solved this by just marking objects to be freed (using a simple double linked list or so), and then in a second phase actually freeing the memory, without any other side effects. Not sure if this applies here, I don't know the details.

[clinuxrulz]

@ziriax that applies here. I've just realized that it is the purpose of the buffered flag (it checks it in release). I originally translated it from a paper without understanding the code. Thanks.

[clinuxrulz]

What I really need to do is a proper test suit for gc-cxx, then use it as a static library for sodium-cxx. There is a multi-threaded version of the gc algorithm in the paper too, that I do not feel like implementing. But someone else might feel like it, so I'll move the project to "SodiumFRP/...", it can be developed independently of sodium-cxx. I should really do the same for Rust too, I've seen another GC library already available for Rust, but it requires "Rust Nightly" instead of "Rust Stable". I'd rather depend on the "Stable" release of Rust rather than the "Unstable" one.

gc-cxx is moved to SodiumFRP as of now.

[the-real-blackh]

The existing C++ version of Sodium was one of my earlier efforts and it has a lot of not-so-good attempts at optimization. I'd like to see it re-written in a much simpler way, more along the lines of the Typescript version.

I'd love to see it work with move semantics instead of passing a pointer to the value around. But this isn't the priority. The priority it getting it working!

[clinuxrulz]

The TypeScript version is really tidy, and I now find it easy to understand. I think people can wait for a TypeScript to C++ translation if that is where we will end up going.

We should have the sodium objects lazyly construction like in the TypeScript version, but remove the requirement for all sodium object to be listened to in order to work correctly. I believe we can achieve this in C++ because we have automatic reference counting (a stack).

[grahamreeds]

What is the canonical version? GR

…

Sent from my Nexus 6P

On 26 Feb 2018 09:18, "Clinton Selke" ***@***.***> wrote: The TypeScript version is really tidy, and I now find it easy to understand. I think people can wait for a TypeScript to C++ translation if that is where we will end up going. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#14 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEy9nFFvWhcy4YEYqMxvBs80RK8y6gN6ks5tYnbegaJpZM4SL9Rd> .

[clinuxrulz]

@grahamreeds the canonical version is the latest version in https://github.com/SodiumFRP/sodium-cxx/releases at the moment.

@the-real-blackh We need to implement finalizers to avoid that seg fault I had before. Why? Because the deconstructor executes methods on objects being referenced by the deconstructing object.

[clinuxrulz]

Finalizers are now supported in gc-cxx (see tests/test_gc.cpp for usage). It won't be as simple as string replacing std::shared_ptr / std::weak_ptr. Some destructor code will need shuffling too.

[clinuxrulz]

Something has just occurred to me. In order to support lazy construction of the sodium object graph, you would be forced to listen to all sodium objects for them to be updated correctly (accum, collect). Unless we could lazyly construct on fire of event rather than listen. This seems like an unnecessary requirement to impose on the end-user, I think we can do better in C++.

I completely understand why we are forced to listen to all sodium objects in TypeScript. Because we really have no choice, its our only means of reference counting. In C++ & Rust we have automatic reference counting, we can do better.

Lets just try and get the current C++ version working as is first. And refactor in the move semantics as we go.

[the-real-blackh]

Great! I didn't know there was a way to do it with GC. I agree - If we can use that, then it would definitely be better.

[clinuxrulz]

I've made a bit of a start of at integrating Gc<>. It looks like a lot of work, so no promises: https://github.com/clinuxrulz/sodium-cxx/tree/gc/sodium . (it uses gc-cxx as a git sub-module)
What remains to make it work, is to do Trace and Finalize trait implementations for all types that contain reachable Gc<>s. Which will lead us implementing lambda1, lambda2 like typescript does so we can trace our closures/lambdas.

I also just saw magic_ref.h. I had no idea that was there. Maybe I should of used it instead. Or use its code to improve Gc<>, like its memory foot print.

[the-real-blackh]

magic_ref.h was an experimental attempt to do something along these lines - I can't remember exactly what.