Jason Orendorff writes:
> On 3/24/14, 2:42 AM, K. Gadd wrote:
>
> There are two collectors.
>
> The JS engine's garbage collector runs more frequently.
> The XPCOM cycle collector runs less often.
That may be true in some scenarios, but I sometimes observe the
cycle collector running more freque
On 03/24/2014 12:55 AM, Jason Orendorff wrote:
and blow that whole window out the air lock.
Actually, we nuke it from orbit.
It's the only way to be sure.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listin
On 3/24/14, 2:42 AM, K. Gadd wrote:
> It is, however, my understanding that cycle collections in
> SpiderMonkey are separate from non-cycle-collections and occur less
> often; is that still true?
There are two collectors.
The JS engine's garbage collector runs more frequently. It collects
cycles
Sorry, when I say manual cycle-breaking I'm referring to cases where
the cycle is kept alive by a root referencing one of the parts of the
cycle. The trivial example of this would be an object with event
listeners registered on it; if all the references are strong, the
object's list of observers ke
On 3/22/14, 7:26 AM, K. Gadd wrote:
> The window and children example is intended to illustrate
> that manual cycle-breaking is non-trivial; in this case it requires a
> robust reference counting mechanism and code audits to ensure
> reference increments/decrements are carefully matched and put in
On 03/23/2014 10:56 PM, Steve Fink wrote:
Anyway, with your specific example, it seems to me that the problem is
that you're losing information. The popups need the main window to
communicate with each other, and the main window needs all of its stuff
to work while it's open. The solution, then,
On 03/23/2014 12:17 AM, Boris Zbarsky wrote:
Say we have this:
observerService.addSettingObserver("data-changed", obj, "cache", null)
and someone sets a "data-changed" notification. If I understand your
proposal correctly, that will do some equivalent of "obj.cache = null",
assuming "obj" is
On 03/19/2014 04:39 PM, Kyle Huey wrote:
> Followup to dev-platform please.
>
> We are discovering a lot of leaks in JS implemented DOM objects. The
> general pattern seems to be that we have a DOM object that also needs
> to listen to events from the message manager or notifications from the
> ob
On 03/21/2014 08:23 PM, K. Gadd wrote:
> A hypothetical scenario (please ignore any minor detail errors, I'm
> using this to illustrate the scenario): Let's say I have a main
> document and it spawns 3 popup windows as documents. The popup windows
> have references to the parent document and use th
On 3/23/14 2:55 AM, Jim Blandy wrote:
I hope we're not talking past each other... the visible behavior of
Services.obs.addObserver("glurph", () => { alert("Glurph!"); }, true)
(pretending that the function supported nsIWeakReference) depends on
when the GC notices the function is garbage. No?
On 03/22/2014 11:36 PM, Boris Zbarsky wrote:
On 3/23/14 2:21 AM, Jim Blandy wrote:
See my slightly longer explanation in the previous message. The
advantage over passing true for ownsWeak is that my proposed API is
completely deterministic.
I'm not sure I follow The current setup in the o
On 3/23/14 2:21 AM, Jim Blandy wrote:
See my slightly longer explanation in the previous message. The
advantage over passing true for ownsWeak is that my proposed API is
completely deterministic.
I'm not sure I follow The current setup in the observer service is
also completely determinis
On 03/22/2014 10:51 PM, Boris Zbarsky wrote:
Or put another way, how does this proposal differ from the already
existing ownsWeak argument of nsIObserverService.addObserver that was
discussed earlier in this thread?
See my slightly longer explanation in the previous message. The
advantage over
On 03/22/2014 10:43 PM, K. Gadd wrote:
> I'm confused about how this would work. who's observing what? How can
> obj be collected if you're passing it as an argument? This looks like
> a synchronous property set passed through an unnecessary intermediary.
Sorry, my code example was confusingly in
On 3/23/14 1:38 AM, Jim Blandy wrote:
For example, suppose we had:
observerService.addSettingObserver(obj, "dirty", true)
which promises to set obj's 'dirty' property to true. If obj is
collected, this observer can obviously be dropped.
How do we know when "obj" is collected?
Or put ano
On 03/19/2014 04:39 PM, Kyle Huey wrote:
Short of not implementing things in JS, what ideas do people have for
fixing these issues? We have some ideas of how to add helpers to
scope these things to the lifetime of the window (perhaps by adding an
API that returns a promise that is resolved at in
Perhaps in some cases weaker, more manageable mechanisms than
full-powered observers and listeners could be sufficient.
For example, one approach which gets you the right cleanup behavior
without exposing GC, is to have special-case observers which can be
easily proven to be safe to drop. For
On Sat, Mar 22, 2014 at 8:26 AM, K. Gadd wrote:
> I mentioned self-hosting to illustrate the need for weak references:
> It's fine that the JS
> environment has no weak reference alternative as long as all the 'hard
> stuff' is
> written in C++, but it seems as if there are reasons to move and
>
I implied that the popups are using the parent document to communicate
with each other (I thought I stated this?). If you retain the parent
document after it is closed in order to keep the child documents
working, now you have a cycle that requires a cycle collector (parent
-> children, children ->
On 3/21/14, 10:23 PM, K. Gadd wrote:
> A hypothetical scenario (please ignore any minor detail errors, I'm
> using this to illustrate the scenario): Let's say I have a main
> document and it spawns 3 popup windows as documents. The popup windows
> have references to the parent document and use them
In many cases the point at which an object becomes uninteresting is
the point at which it is unreachable, and no deterministically
identifiable point before that. It is true that in many cases you
don't need anything resembling weak references, and can simply
manually mark objects as dead. There ar
On 3/21/14 10:14 PM, Jim Blandy wrote:
It's true that when I read, "We are discovering a lot of leaks in JS
implemented DOM objects", I wasn't sure what he was referring to...
He means APIs exposed to the web whose implementation is a JS component.
So typically these are objects whose useful l
On 03/21/2014 05:03 PM, Boris Zbarsky wrote:
On 3/21/14 6:34 PM, Jim Blandy wrote:
I don't believe there are any DOM nodes involved in the situation that
Kyle described at the start of this thread...
It's true that when I read, "We are discovering a lot of leaks in JS
implemented DOM objects",
On 3/21/14 6:34 PM, Jim Blandy wrote:
What if these DOM nodes
I don't believe there are any DOM nodes involved in the situation that
Kyle described at the start of this thread...
-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
h
On 3/21/14, 5:42 PM, Jim Blandy wrote:
> On 03/21/2014 03:34 PM, Jim Blandy wrote:
>> What if these DOM nodes could use a special class of observers /
>> listeners that automatically set themselves aside when the node is
>> deleted from the document, and re-instate themselves if the node is
>> re-i
On 03/21/2014 03:34 PM, Jim Blandy wrote:
What if these DOM nodes could use a special class of observers /
listeners that automatically set themselves aside when the node is
deleted from the document, and re-instate themselves if the node is
re-inserted in the document? Similarly for when the win
On 03/19/2014 04:39 PM, Kyle Huey wrote:
Short of not implementing things in JS, what ideas do people have for
fixing these issues? We have some ideas of how to add helpers to
scope these things to the lifetime of the window (perhaps by adding an
API that returns a promise that is resolved at in
On 03/20/2014 12:37 PM, David Rajchenbach-Teller wrote:
So basically, you want to add a finalizer for JS component?
No. It would be callback to tell when the thing (wrappedJS) we have a weakref to
is going away. And wrappedJS keeps then a weak ref to the JS object.
As far as I see, this would b
Keep in mind that es-discuss has hosted frequent, detailed discussions
on the topic of weak references and it is quite possible that they
could be introduced in ES7 or ES8 (at least based on what has been
said on the list), due to their requirement for solving certain
problems in large-scale applic
So basically, you want to add a finalizer for JS component?
Note that we already have a weak (post-mortem) finalization module for
JS, hidden somewhere in mozilla-central. It's not meant to be used for
performance critical code, and it provides no guarantees about cycles,
but if this is necessary,
On 20/03/2014 02:25, Boris Zbarsky wrote:
On 3/19/14 9:41 PM, Justin Dolske wrote:
It uses a weak reference with the observer service, plus a dummy strong
reference (via addEventListener()) to automatically manage the
lifetime... When the node/document does away, so does the event listener.
Th
Ehsan Akhgari writes:
> On 2014-03-19, 10:50 PM, Boris Zbarsky wrote:
>> On 3/19/14 10:40 PM, Ehsan Akhgari wrote:
>>> Why do we have to touch that list on shutdown?
>>
>> We Release() all the things in it (nsIWeakReferences in this case).
>
> Well, that was sort of my point (gotta work on my styl
On 2014-03-19, 10:50 PM, Boris Zbarsky wrote:
On 3/19/14 10:40 PM, Ehsan Akhgari wrote:
Why do we have to touch that list on shutdown?
We Release() all the things in it (nsIWeakReferences in this case).
Well, that was sort of my point (gotta work on my style of being overly
terse, sorry abo
On 3/19/14 10:40 PM, Ehsan Akhgari wrote:
Why do we have to touch that list on shutdown?
We Release() all the things in it (nsIWeakReferences in this case).
That said, the "minutes" cases are the ones where the notification is
one that's actually fired at shutdown, because then we start remov
On 2014-03-19, 10:25 PM, Boris Zbarsky wrote:
On 3/19/14 9:41 PM, Justin Dolske wrote:
It uses a weak reference with the observer service, plus a dummy strong
reference (via addEventListener()) to automatically manage the
lifetime... When the node/document does away, so does the event listener.
On 3/19/14 9:41 PM, Justin Dolske wrote:
It uses a weak reference with the observer service, plus a dummy strong
reference (via addEventListener()) to automatically manage the
lifetime... When the node/document does away, so does the event listener.
This is sort of ok for notifications that fir
On 2014-03-19, 7:58 PM, Kyle Huey wrote:
On Wed, Mar 19, 2014 at 4:52 PM, David Rajchenbach-Teller
wrote:
Couldn't we insist that any reference to a DOM element in JS (or at
least in JS-implemented components) must be a weak pointer-style
wrapper? I seem to remember that we have introduced some
On 3/19/14 4:39 PM, Kyle Huey wrote:
We are discovering a lot of leaks in JS implemented DOM objects. The
general pattern seems to be that we have a DOM object that also needs
to listen to events from the message manager or notifications from the
observer service, which usually hold strong refe
On 03/20/2014 02:25 AM, smaug wrote:
On 03/20/2014 01:58 AM, smaug wrote:
On 03/20/2014 01:39 AM, Kyle Huey wrote:
Followup to dev-platform please.
We are discovering a lot of leaks in JS implemented DOM objects. The
general pattern seems to be that we have a DOM object that also needs
to lis
On 03/20/2014 01:58 AM, smaug wrote:
On 03/20/2014 01:39 AM, Kyle Huey wrote:
Followup to dev-platform please.
We are discovering a lot of leaks in JS implemented DOM objects. The
general pattern seems to be that we have a DOM object that also needs
to listen to events from the message manager
On 03/20/2014 01:39 AM, Kyle Huey wrote:
Followup to dev-platform please.
We are discovering a lot of leaks in JS implemented DOM objects. The
general pattern seems to be that we have a DOM object that also needs
to listen to events from the message manager or notifications from the
observer se
On Wed, Mar 19, 2014 at 4:52 PM, David Rajchenbach-Teller
wrote:
> Couldn't we insist that any reference to a DOM element in JS (or at
> least in JS-implemented components) must be a weak pointer-style
> wrapper? I seem to remember that we have introduced something along
> these lines a few years
Couldn't we insist that any reference to a DOM element in JS (or at
least in JS-implemented components) must be a weak pointer-style
wrapper? I seem to remember that we have introduced something along
these lines a few years ago as a way to fight against leaks of
references to DOM by add-ons.
On 3
Followup to dev-platform please.
We are discovering a lot of leaks in JS implemented DOM objects. The
general pattern seems to be that we have a DOM object that also needs
to listen to events from the message manager or notifications from the
observer service, which usually hold strong references
44 matches
Mail list logo
