14543 - shutdown JS component loader

Status: RESOLVED FIXED

(Core :: XPCOM, defect, P2)

Description

[Bruce Mitchener]

must unload JS components otherwise lots of evil leaks. this means shutting down
the js component loader.

Comment 1

[John Bandhauer]

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.

Comment 2

[Mike Shaver (:shaver emeritus)]

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.

Comment 3

[Mike Shaver (:shaver emeritus)]

I've got the shutdown routines running, but I don't get called in the
interesting cases.  The saga continues....

Comment 4

[chris hofmann]

m12.  let me know if fix becomes available in the next couple of days.

Comment 5

[Mike Shaver (:shaver emeritus)]

All done.

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/cff38fe61e48
[fenix] For https://github.com/mozilla-mobile/fenix/issues/14543 - Prevents IllegalStateException by not moving to another thread