
Implementing Garbage Collection in CS/JS with Aspect-Oriented Programming - llambda
https://github.com/raganwald/homoiconic/blob/master/2012/03/garbage_collection_in_coffeescript.md#readme
======
justncase80
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
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?

~~~
justncase80
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
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.

