ObserverCallbacks continues growing with dead callback

[naqtn]

Object.observe() appends the callback to [[ObserverCallbacks]] . On the other hand, Object.unobserve() does not care about [[ObserverCallbacks]] . Then [[ObserverCallbacks]] continues growing big with unused callback while the system runs.

I implemented current specification straight forward, then I encountered this problem.

I think Object.unobserve() should remove it. Or, somewhere in delivering steps (the end of AllChangeRecords ?) might be better point. because records in [[PendingChangeRecords]] could remain if Object.unobserve() immediately removes.

[arv]

The spec only describes semantics. Things like GC is unobservable. An implementation needs to make sure that it cleans up unreachable objects.

It is possible that we need to make something clearer in the spec here?

[arv]

The spec uses the term "List" which is an implementation specific data structure.

[naqtn]

(I posted a comment but it was unclear. I rewrite.)

I've thought even if internal property is not directly accessible via ECMAScript code, but acts like usual ECMAScript Object (especially reachability manner in this case). The event queue holds [[ObserverCallbacks]], and [[ObserverCallbacks]] holds "unused callback", and I think "unused callback" is reachable after Object.unobserve().

Is it incorrect?

If I misunderstand, who holds strong referrence? After Object.observe() called, the callback can be refered only from two paths. (User main program can release it. right?)

1. user main program => observable => [[Notifier]] => [[ChangeObservers]] => record =([[Callback]])=> callback
2. event queue => [[ObserverCallbacks]] => callback

If [[ObserverCallbacks]] behaves like weak referrence, how about first internal properties? And strictly when the callback becomes garbage Object.unobserve() after called?

P.S.

"List" which is an implementation specific data

Well.., I'll read the spec again carefully.