shutdown JS component loader

RESOLVED FIXED in M12

Status

()

P2
major
RESOLVED FIXED
19 years ago
19 years ago

People

(Reporter: bruce, Assigned: shaver)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

19 years ago
must unload JS components otherwise lots of evil leaks. this means shutting down
the js component loader.
(Reporter)

Updated

19 years ago
Priority: P3 → P2
Target Milestone: M11

Comment 1

19 years ago
Why is this? What leaks?

In today's xpconnect killing the JSContext of the wrapped JS object will cause
xpconnect to release its root on the object (if it is holding one) and to make
the JS object unreachable via xpconnect. Native 'users' of the object still
hold a reference to a wrapper, but the wrapper will return a failure code on
all method calls. This is generally whacky. And will be fixed in time.

It will not work that way in the future. After xpconnect is fixed, xpconnect
will hold its root as long as the JSRuntime of the JS object is alive and any
native code has a reference to the wrapper for the JS object. This is not a
leak. It is use.

Given the current state where killing the JSContext blindly 'kills' the link
between the user of the object and the object, how do you decide which
components to kill and/or when to unload the loader?

In the future scheme unloading the loader leaves the components which are in use
in place. However, reloading the loader and instantiating the 'same' service
implemented in JS will potentially cause two different implementation object of
the same service (implemented in JS) to be running at the same time. This
violates the 'service contract' :) This state is to be avoided.

My original plan was to have the loader ask the js module if it wants to be
unloaded or not and then respect its decision. It *any* of the loaded JS modules
want to stick around, then the loader should not unload.

Please explain why this is a problem.

It seems to me that the only cost we will pay is the cost of keeping the loader
around and the cost of holding on to any js modules that refuse to be unloaded.
This is pretty much the same as the native case. I think, that shutting down the
loader (except on final shutdown) would be right nasty.
Status: NEW → ASSIGNED
We're talking about final shutdown, where all the various items entrained by the
JSContext and component-globals appear to leak, thus causing much grief for
purify-users.

Updated

19 years ago
QA Contact: beppe → gerardok
I've got the shutdown routines running, but I don't get called in the
interesting cases.  The saga continues....

Updated

19 years ago
Target Milestone: M11 → M12

Comment 4

19 years ago
m12.  let me know if fix becomes available in the next couple of days.
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.