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
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 still
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 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
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
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 frequently
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
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
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
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?
Ah,
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 them
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 Sat, Mar 22, 2014 at 8:26 AM, K. Gadd k...@luminance.org 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
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 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
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
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
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
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
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,
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
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 to
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.
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
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
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
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
On Wed, Mar 19, 2014 at 4:52 PM, David Rajchenbach-Teller
dtel...@mozilla.com 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
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
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
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
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
On 2014-03-19, 7:58 PM, Kyle Huey wrote:
On Wed, Mar 19, 2014 at 4:52 PM, David Rajchenbach-Teller
dtel...@mozilla.com 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
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
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 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
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
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 style of being
38 matches
Mail list logo
