4 ms·

I'm not sure you can actually call this garbage collection. It seems like manual memory management to me. Javascript actually has a GC but this seems like it's

I'm not sure you can actually call this garbage collection. It seems like manual memory management to me. Javascript actually has a GC but this seems like it's trying to ride off the novelty of the idea of implementing a GC in a language that already has a GC... but I'm not convinced that is what is actually happening.

raganwald 15y ago
In one part of the program you call functions and pass values around. In another part, you count references and keep an eye on the size of the cache. When it is too full, you throw away the items that aren’t referenced. How is this not garbage collection?
- apk17 15y ago
  Garbage collection is throwing away stuff that can't be reached anymore. What you're doing is cache eviction; dereferencing stuff you probably don't need so it becomes garbage and won't occupy memory for long. Although that is possibly a battle of definitons.
- justncase80 15y ago
  I suppose it's just semantics. The fact that you're actually writing the code yourself to do reference counting and releasing of the references is what makes me think it's not garbage collection, it's manual. When you drop the reference, then it actually becomes garbage and the javascript GC will free it sometime after that.
  - apk17 15y ago
    Refcounting is usually considered garbage collection - if going to zero means deallocation the refcounted object. But here we (fsvo) merely use the refcount to not drop objects out of the hashmap while they are in use, and a specific algorithm is employed that decides which objects are actually removed (and thus later dropped by the JS GC). This is much like WeakRef/WeakHashMap, with the difference that the decision which objects are dropped is not random/up to the GC implementor. And because of those two thing - dropping things out of the cache isn't random, and it is not triggered by actually running low on memory (is it not?) - I'd not consider this GC. GC tries to keep the illusion of infinite space, and this algo explicitly codes to a specific amount of available space.
silentbicycle 15y ago
It's not at all unusual to have to manage the lifetime of data in a cache, particularly in languages like Javascript that do not support weak references.

raganwald 15y ago

In one part of the program you call functions and pass values around. In another part, you count references and keep an eye on the size of the cache. When it is too full, you throw away the items that aren’t referenced. How is this not garbage collection?

apk17 15y ago
Garbage collection is throwing away stuff that can't be reached anymore. What you're doing is cache eviction; dereferencing stuff you probably don't need so it becomes garbage and won't occupy memory for long. Although that is possibly a battle of definitons.
justncase80 15y ago
I suppose it's just semantics. The fact that you're actually writing the code yourself to do reference counting and releasing of the references is what makes me think it's not garbage collection, it's manual. When you drop the reference, then it actually becomes garbage and the javascript GC will free it sometime after that.
- apk17 15y ago
  Refcounting is usually considered garbage collection - if going to zero means deallocation the refcounted object. But here we (fsvo) merely use the refcount to not drop objects out of the hashmap while they are in use, and a specific algorithm is employed that decides which objects are actually removed (and thus later dropped by the JS GC). This is much like WeakRef/WeakHashMap, with the difference that the decision which objects are dropped is not random/up to the GC implementor. And because of those two thing - dropping things out of the cache isn't random, and it is not triggered by actually running low on memory (is it not?) - I'd not consider this GC. GC tries to keep the illusion of infinite space, and this algo explicitly codes to a specific amount of available space.

silentbicycle 15y ago

It's not at all unusual to have to manage the lifetime of data in a cache, particularly in languages like Javascript that do not support weak references.