
Show HN: A pure reference counting GC in Go - sendilkumarn
https://github.com/sendilkumarn/gopurerc
======
gwbas1c
Just curious: Does this do anything to avoid the need to explicitly close
resources in a garbage collected environment? (IE, the Disposable pattern in
C# / .Net)

Specifically, when I work in a reference-counted environment, if an object has
a resource, like an open file, or a socket, I don't need to do anything
special when I'm done with that object. The reference count predictably drops
when I'm done with the object, and its destructor cleans up its resources.

In contrast, because garbage collection is non-deterministic, in a garbage
collected environment, I have to use extra special care when an object uses a
resource (file, socket, ect,) that needs to be released at a predictable
moment.

Because: If, in a garbage collected environment, the rule of thumb is to "make
sure you don't have circular references to your resources, (files, sockets,
ect,)" this would dramatically simplify resource (not memory) management!

~~~
marcoperaza
Even in a reference counted or RAII environment, you still have to think about
this. Your C++ function might do something with a file (or other resource) and
then a bunch of other stuff, or vice-versa. If you care about holding that
resource open for as little time as possible, you need to consciously
introduce a new anonymous scope where the resource object and operations are
contained (or, of course, you could break it out into another function).

------
maxgraey
By the way concurrent algorithm described in paper has couple of bugs that
were found and corrected by dcodeIO during prototyping this GC/RC for
AssemblyScript:

[https://github.com/dcodeIO/purerc](https://github.com/dcodeIO/purerc)

~~~
sendilkumarn
Yeah I think this one has that fix. Infact, it is inspired from purerc :)

------
ckok
Quite cool. But I miss the part where you can actually use the objects
themselves to store something in. What's your goal here? To have a real usable
gc, becuase if so, it should probably allocate outside the Go heap, and
directly from the OS? Also the fields should probably be packed:

    
    
       Name      string
       Rc        int
       Crc       int
       Color     string
       Buffered  bool
       Children  []*Object
       Freed     bool
       isAcyclic bool
    

as those seem to have quite a bit of overhead for an object.

~~~
sendilkumarn
I completely agree. My goal here is to learn and debug what is happening.
(intention is to backport this into tinygo)

There are a plenty of steps to make it into usable gc.

~~~
ckok
Ah that makes sense. I did the "non thread safe" version of this paper for our
webassembly support (Because at the time, Boehm didn't support it)
[https://github.com/remobjects/IslandRTL/blob/master/Source/S...](https://github.com/remobjects/IslandRTL/blob/master/Source/SimpleGC.pas)

But the threadsafe one does have a lot of raw edges, and I couldn't get that
one working.

~~~
sendilkumarn
Thats cool.

I think assemblyscript has implemented it. Something you might be interested
to explore

~~~
ckok
yeah. But for multithreaded I figure there's little chance I can do better
than Boehm (especially considering the testing involved in this).

------
icholy
The code doesn't build and is extremely racy.

edit: I fixed the import cycles and got it to build, but now the tests don't
pass. The more of this code I read ... the worse it gets. Why is this on top
of HN?

------
kstenerud
This is quite cool. I love seeing new research into reference counting systems
since they seem to have fallen out of favor vs mark/sweep and such (ARC
notwithstanding).

~~~
pjmlp
They were never in favor, because any reference counting implementation that
matches tracing GC in performance, specially on multi-core machines, ends up
being a tracing GC in disguise.

~~~
kstenerud
Has this been proven?

If not, there's room for more research.

~~~
jashmatthews
Yup. Discussed here before!
[https://news.ycombinator.com/item?id=14823054](https://news.ycombinator.com/item?id=14823054)

