7 ms·

Show HN: A pure reference counting GC in Go

57 points by sendilkumarn 7y ago

ckok 7y ago
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 7y ago
  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 7y ago
    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/SimpleGC.pas https://github.com/remobjects/IslandRTL/blob/master/Source/S... But the threadsafe one does have a lot of raw edges, and I couldn't get that one working.
    - sendilkumarn 7y ago
      Thats cool. I think assemblyscript has implemented it. Something you might be interested to explore
      - ckok 7y ago
        yeah. But for multithreaded I figure there's little chance I can do better than Boehm (especially considering the testing involved in this).
deleted 7y ago
[deleted]
kstenerud 7y ago
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 7y ago
  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.
  - DagAgren 7y ago
    One of the biggest OSes today is running nearly entirely on reference counting, so I think it's safe to say they are actually in favour.
    - pjmlp 7y ago
      If you mean iOS, it is more a side effect of the project failure to add GC to Objective-C than anything else. Also reference counting only applies to a tiny subset of Objective-C data structures, classes derived from NSObject using Cocoa retain/release patterns. If you add Swift to the soup, there is still quite some work to do regarding performance, https://github.com/ixy-languages/ixy.swift/blob/master/performance/README.md https://github.com/ixy-languages/ixy.swift/blob/master/perfo... The other, even bigger OS, is running on tracing GCs. And Windows is running on a mix of reference counting and tracing GC.
      - tomp 7y ago
        Isn’t one of the benefits of RC better (lower and more predictable) latency than with GC? Basically, you can presict when (and how much) garbage will be collected, and if it turns out that’s too much, you can fix your code... good luck doingthat with GC. The downside is, of course, that it requires much more care (to avoid cycles)
        7y ago
gwbas1c 7y ago
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 7y ago
  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).
icholy 7y ago
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?
maxgraey 7y ago
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 7y ago
  Yeah I think this one has that fix. Infact, it is inspired from purerc :)

57 points by sendilkumarn 7y ago

ckok 7y ago

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 7y ago
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 7y ago
  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/SimpleGC.pas https://github.com/remobjects/IslandRTL/blob/master/Source/S... But the threadsafe one does have a lot of raw edges, and I couldn't get that one working.
  - sendilkumarn 7y ago
    Thats cool. I think assemblyscript has implemented it. Something you might be interested to explore
    - ckok 7y ago
      yeah. But for multithreaded I figure there's little chance I can do better than Boehm (especially considering the testing involved in this).

deleted 7y ago

[deleted]

kstenerud 7y ago

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 7y ago
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.
- DagAgren 7y ago
  One of the biggest OSes today is running nearly entirely on reference counting, so I think it's safe to say they are actually in favour.
  - pjmlp 7y ago
    If you mean iOS, it is more a side effect of the project failure to add GC to Objective-C than anything else. Also reference counting only applies to a tiny subset of Objective-C data structures, classes derived from NSObject using Cocoa retain/release patterns. If you add Swift to the soup, there is still quite some work to do regarding performance, https://github.com/ixy-languages/ixy.swift/blob/master/performance/README.md https://github.com/ixy-languages/ixy.swift/blob/master/perfo... The other, even bigger OS, is running on tracing GCs. And Windows is running on a mix of reference counting and tracing GC.
    - tomp 7y ago
      Isn’t one of the benefits of RC better (lower and more predictable) latency than with GC? Basically, you can presict when (and how much) garbage will be collected, and if it turns out that’s too much, you can fix your code... good luck doingthat with GC. The downside is, of course, that it requires much more care (to avoid cycles)
      - 7y ago

gwbas1c 7y ago

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 7y ago
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).

icholy 7y ago

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?

maxgraey 7y ago

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 7y ago
Yeah I think this one has that fix. Infact, it is inspired from purerc :)