4 ms·

Yeah, but the pause is completely deterministically in control of your program. Doing cycle collection basically ends up as hard as full GC right? Annotating w

by dilap 10y ago

Yeah, but the pause is completely deterministically in control of your program. Doing cycle collection basically ends up as hard as full GC right? Annotating with weak is not a big deal.

kartickv 10y ago
> The pause is completely deterministically in control of your program. In theory. In practice, the programmer may not be able to reproduce the pause to diagnose and fix it, or it may not bubble up to the top of the priority list. Whereas with a GC, this problem may not occur at all in the first place. The question is whether such cases (large object graph or linked list) occur often enough in practice to be worth bothering about.
cmrdporcupine 10y ago
> Doing cycle collection basically ends up as hard as full GC right? Not really. Yes you do need to have the ability to trace the object graph. But the actual algorithm isn't that bad. I implemented this in C++ (for "fun" for a pet language VM i wrote) 15 years ago: http://researcher.watson.ibm.com/researcher/files/us-bacon/Bacon01Concurrent.pdf http://researcher.watson.ibm.com/researcher/files/us-bacon/B...
- bjourne 10y ago
  That's interesting! I also implemented that algorithm for cycle collection (https://github.com/bjourne/c-examples/blob/master/libraries/collectors/ref-counting-cycles.c https://github.com/bjourne/c-examples/blob/master/libraries/...) and I found that like the GP states that it wasn't worth it. The problem was that there so many objects that were potentially part of garbage cycles that it required scanning a too large part of the heap. Cycle detection took about 70% as long a full mark and sweep collection so I didn't think it was worth it considering how complicated the algorithm was. Is your implementation open source? If so, I'd love to see it and compare results.
  - cmrdporcupine 10y ago
    I guess it's technically open source but it's old (15 year old C++) and based heavily on the pseudo-code in the paper and also tied heavily into the interpreter I was working on. I didn't do a lot of performance testing either. The interpreter I was working on was for a language which was image-based and persistent, I guess much like a Smalltalk, etc. Reference counting was handy for aiding in determining when objects should be pages to/from the disk image and what should be in cache. I think performance would depend a lot on the usage pattern of the object graph. My system also used a lot of immutable data. The only mutable structures were the objects that properties and methods hung off of, and hash tables.

by dilap 10y ago

Yeah, but the pause is completely deterministically in control of your program. Doing cycle collection basically ends up as hard as full GC right? Annotating with weak is not a big deal.

kartickv 10y ago

> The pause is completely deterministically in control of your program. In theory. In practice, the programmer may not be able to reproduce the pause to diagnose and fix it, or it may not bubble up to the top of the priority list. Whereas with a GC, this problem may not occur at all in the first place. The question is whether such cases (large object graph or linked list) occur often enough in practice to be worth bothering about.

cmrdporcupine 10y ago

> Doing cycle collection basically ends up as hard as full GC right? Not really. Yes you do need to have the ability to trace the object graph. But the actual algorithm isn't that bad. I implemented this in C++ (for "fun" for a pet language VM i wrote) 15 years ago: http://researcher.watson.ibm.com/researcher/files/us-bacon/Bacon01Concurrent.pdf http://researcher.watson.ibm.com/researcher/files/us-bacon/B...

bjourne 10y ago
That's interesting! I also implemented that algorithm for cycle collection (https://github.com/bjourne/c-examples/blob/master/libraries/collectors/ref-counting-cycles.c https://github.com/bjourne/c-examples/blob/master/libraries/...) and I found that like the GP states that it wasn't worth it. The problem was that there so many objects that were potentially part of garbage cycles that it required scanning a too large part of the heap. Cycle detection took about 70% as long a full mark and sweep collection so I didn't think it was worth it considering how complicated the algorithm was. Is your implementation open source? If so, I'd love to see it and compare results.
- cmrdporcupine 10y ago
  I guess it's technically open source but it's old (15 year old C++) and based heavily on the pseudo-code in the paper and also tied heavily into the interpreter I was working on. I didn't do a lot of performance testing either. The interpreter I was working on was for a language which was image-based and persistent, I guess much like a Smalltalk, etc. Reference counting was handy for aiding in determining when objects should be pages to/from the disk image and what should be in cache. I think performance would depend a lot on the usage pattern of the object graph. My system also used a lot of immutable data. The only mutable structures were the objects that properties and methods hung off of, and hash tables.