3 ms·

> Reference counting GC with loops detection I'm interested in exploring the state of memory management in between pure ownership trees and all-out GC, includi

> Reference counting GC with loops detection I'm interested in exploring the state of memory management in between pure ownership trees and all-out GC, including stack-allocated structs, refcounting, cycle collection, and per-thread-enabled GCs. I found https://bellard.org/quickjs/quickjs.html https://bellard.org/quickjs/quickjs.html and https://news.ycombinator.com/item?id=20413561 https://news.ycombinator.com/item?id=20413561 when looking for more information on QuickJS's cycle removal, which mentions the "Bacon cycle collector".

ipodopt 5y ago
https://scholar.google.com/citations?user=guNVlmIAAAAJ&hl=en&oi=sra https://scholar.google.com/citations?user=guNVlmIAAAAJ&hl=en... https://scholar.google.com/scholar?hl=en&as_sdt=0%2C10&q=bacon+cycle+collection&oq=bacon+cycle https://scholar.google.com/scholar?hl=en&as_sdt=0%2C10&q=bac... Probably specifically refers to "Concurrent cycle collection in reference counted systems" where Bacon is first author?
c-smile 5y ago
Ref-counting GC and in particular implementation that is used in QuickJS is more deterministic I would say. In QuickJS: function Foo() { let file = new File(...); file.write("Happy New Year"); } The file variable (object in it) will be destroyed immediately at the exit from the function. Which is more suitable in case of Sciter that is embeddable [in native applications] engine. Contrary my TIScript that I was using before had real moving/compacting GC. Objects were freed at GC cycles (in galaxy far far away from invocation).
- pjmlp 5y ago
  In such basic example yes. Now try an data structure, with an unknown size of elements that can non-deterministically scale to several hundreds nodes and delete the graph root node. Which is why all high performance Ref-counting GC rely on background threads for when RC reaches zero, thus mimicking tracing GC implementations.
  - nyanpasu64 5y ago
    Is this substantially worse than deleting a vector<unique_ptr> holding a few hundred nodes (which I don't really notice, but might be bad without me realizing)? Either way you're doing a traversal and running hundreds of destructors and deallocations, but in the refcount you need an extra deallocation and compare per node (which should be cheap compared to deallocation, if non-atomic?).
    - pjmlp 5y ago
      About the same, Herb Sutter has a talk how that can even trigger stack overflow if the destructors are not written with care. "CppCon 2016: Herb Sutter “Leak-Freedom in C++... By Default.” https://youtu.be/JfmTagWcqoE https://youtu.be/JfmTagWcqoE By the way, C++/WinRT uses background threads to handle cascade deletions of COM references exactly because of this.

ipodopt 5y ago

https://scholar.google.com/citations?user=guNVlmIAAAAJ&hl=en&oi=sra https://scholar.google.com/citations?user=guNVlmIAAAAJ&hl=en... https://scholar.google.com/scholar?hl=en&as_sdt=0%2C10&q=bacon+cycle+collection&oq=bacon+cycle https://scholar.google.com/scholar?hl=en&as_sdt=0%2C10&q=bac... Probably specifically refers to "Concurrent cycle collection in reference counted systems" where Bacon is first author?

c-smile 5y ago

Ref-counting GC and in particular implementation that is used in QuickJS is more deterministic I would say. In QuickJS: function Foo() { let file = new File(...); file.write("Happy New Year"); } The file variable (object in it) will be destroyed immediately at the exit from the function. Which is more suitable in case of Sciter that is embeddable [in native applications] engine. Contrary my TIScript that I was using before had real moving/compacting GC. Objects were freed at GC cycles (in galaxy far far away from invocation).

pjmlp 5y ago
In such basic example yes. Now try an data structure, with an unknown size of elements that can non-deterministically scale to several hundreds nodes and delete the graph root node. Which is why all high performance Ref-counting GC rely on background threads for when RC reaches zero, thus mimicking tracing GC implementations.
- nyanpasu64 5y ago
  Is this substantially worse than deleting a vector<unique_ptr> holding a few hundred nodes (which I don't really notice, but might be bad without me realizing)? Either way you're doing a traversal and running hundreds of destructors and deallocations, but in the refcount you need an extra deallocation and compare per node (which should be cheap compared to deallocation, if non-atomic?).
  - pjmlp 5y ago
    About the same, Herb Sutter has a talk how that can even trigger stack overflow if the destructors are not written with care. "CppCon 2016: Herb Sutter “Leak-Freedom in C++... By Default.” https://youtu.be/JfmTagWcqoE https://youtu.be/JfmTagWcqoE By the way, C++/WinRT uses background threads to handle cascade deletions of COM references exactly because of this.