From Gnash Project Wiki

Jump to: navigation, search

discussions and questions about the GC

a) "Anyway the idea is NOT to use a separate thread for collecting but rather doing it all in a predictable order from the main thread."

Agree, a predictable order is important.

b) "Now, keeping the same kind of interface would be possible but no object will be destroied till the garbage collector runs."

It will be good that the current interface still works untill the new GC is sufficiently qualified. Take a look at the following code:

for(var i=0; i<big_number; i++)
  var obj = new big_object();
  delete obj();

will this code consumes too much memory than needed caused by the latence of the GC? will this be a problem in future?

It might be a problem, but currently we discourage explicit deletion anyway. Of course the problem remains if you used to store the newly allocated object into an intrusive_ptr, as it would be automatically deleted when exiting the scope.... Allowing explicit deletion would require being sure that NO other pointers reference that same point. How could we do that ? The only way I can think of is keeping the ref-counting.

Deletion/destory of objects in a flash player happens in two ways:

(1) explicit deletion: handled by a few ActionSrcipts directly, eg. ActionDelete, ActionDelete2, ActionRemoveSpite and some other built-in fuctions(not many).

(2) implicit deletion: handled by playhead, eg. happens when gotoFrame and loop-back occurs.

The explicit deletion is handled as a drop of references, so next GC run will collect that memory, same thing for implicit deletion

c) "Circular dependencies are not properly handled. A set of ref-counted resources forming a chain is *never* deallocated. This simple ActionScript code shows the problem:"

  var a  = new Object;
  a.member = a;
  delete a;  // ActionDelete or ActionDelete2

"The a value will never be released as it would contain a reference to itself, so its refcount will be 1 forever. "

I understand the circular reference in the above example. But cann't we delete the resource when we sure enough we can do that in this case(told by the opcode)?In my view, this is a question of implementing ActionDelete, not question of the rationale of using smart pointers.

IMHO, all non-character as_object are deleted explicitly by some AS opcodes or built-in methods. I think(not sure enough) we should delete them immediately when we encounter these opcodes or methods. This is the work we need to do to implement those opcodes and built-in methods(not many).

They are never explicitly deleted right now, just the property is removed, so currenlty ref-count decremented. Eventually (if refcount is 0) it will be deleted, but it's not ensured.

For all characters, they might be deleted either explicitly or implicitly. If we had a GC for this to reduce the memory management work, it will be great.

I have a feeling that at the first step, we might just need a GC for characters, just some pre-mature opinions.

The most important use of the GC is for ActionScript objects, more then for characters. Characters have a hierarchical relationship, so it's not possible to have circular references.