115450 - XPCom Plugins should be unloaded when not in use

Status: RESOLVED INVALID

(Core Graveyard :: Plug-ins, defect)

Description

[Carl Fink]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.6) Gecko/20011120
BuildID:    2001112012

When I visit a page with a Java applet, multiple Java Virtual Machines open. 
When I leave, they NEVER close.  At the moment ps shows 18 java_vm processes
(and 5 mozilla_bin processes).

If this is a bug in the Java plugin from Sun, my apologies.

Reproducible: Always
Steps to Reproduce:
1.Visit a Java applet-containing page
2.Leave


Actual Results:  java_vm processes don't ever close.

Expected Results:  They should.

Comment 1

[Boris Zbarsky [:bzbarsky]]

These are not processes.  They are threads.  This applies to both java_vm and 
mozilla-bin.  Once the java vm starts (a single process) it starts a number of 
threads.  The threads _are_ pruned, but they are usually not pruned below about 
15 or so, since that seems to be how many are needed to run a typical applet.

If you feel that the VM should prune threads more agressively, that would be a 
bug against the VM, yes.

Comment 2

[Carl Fink]

Boris Zbarsky's comment doesn't actually resolve my complaint.  Whether they're
called "processes" or "threads", why should the Java VM remain open, forever,
after I visit one Java-using web page?  Why should ANY plugin stay loaded,
forever, after it's no longer in use?  Does RealPlayer or Flash do this, too? 
Should the bug be generalized?

By the way, under Linux each thread IS a process, making Boris' distinction even
less useful in this case.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Well.... starting the java vm takes a while.  The assumption is that once you 
hit a page that uses the vm you will continue using java pages and so unloading 
the plugin every time a page is unloaded and restarting it every time a page is 
loaded is pointless.

> under Linux each thread IS a process

Um... not quite.  Threads share memory, processes do not.  Thus threads are 
actually much lower overhead than processes (you just have to keep track of 
their existence, which is low memory overhead).  Yes, both do eat up process 
table entries.  :)

Resummarizing to reflect the real problem and confirming for consideration.

Comment 4

[Peter Lubczynski]

NPAPI plugins are unloaded right after the last instance is destroyed. Java is
the main-stream XPCOM plugin for UNIX (that I know works). XPCOM plugins were
designed to stay resident until the browser quit, for performance reasons. In
any case, this is a dup of bug 85319 and the Sun guys marked it INVALID.

Try JRE 1.4. It has many bug and performance fixes over 1.3.1.

*** This bug has been marked as a duplicate of 85319 ***

Comment 5

[shrirang khanzode]

v d

Comment 6

[Carl Fink]

Dunno if this is a new bug or the same one:  I visited http://cartalk.cars.com/
and played their current show using the RealPlayer helper app.  Mozilla became
unstable, requiring several reloads to show any page.  (That isn't necessarily
what I am reporting.)  I therefore exited Mozilla, leaving the RealPlayer
running.  I got the message from the shell that Mozilla had exited BUT THE
JAVA_VM THREADS (18 of them) REMAINED VISIBLE IN PS.

One could argue that it's wise to keep the VM loaded, even when the browser
window contains no applets.  However, keeping it loaded after the browser exits
is harder to defend, I think.

If this is a new bug, sorry for misplacing it.

Comment 7

[av (gone)]

--- Mass reassigning Unix bugs to serge ---

Comment 8

[Michael Hendy (Hendikins)]

*** Bug 121212 has been marked as a duplicate of this bug. ***

Comment 9

[Christopher Aillon (sabbatical, not receiving bugmail)]

*** Bug 126208 has been marked as a duplicate of this bug. ***

Comment 10

[brian]

I'd like to propose a simple solution of having a timer for unloading plugins if
tbey haven't been used for at least some threshold amount of time. Mozilla uses
too much memory (over 138MB on my system right now *without* including plugins!)
and any way of lessening its requirements is a good thing.

A simple global timer for all plugins with a pref panel entry such as 'unload
plugins when not used for at least __ minutes' would do the trick. set the
default at 10 minutes or so.

Also, can we change the platform to 'ALL'? (i'm using windows)

Comment 11

[brian]

Should this bug be dependent on bug 153001?

Comment 12

[serge (gone)]

old school (ns4.x based) plugins are getting unloaded,
bug 153001 is about safety unloading scriptable plugin.
java plugin is true XPCOM plugin, it's almost like XPCOM component
(you never know who is keepping refs on what)
and current XPCOM implementation does not support unloading XPCOM dll:(
I'm sure there is a bug report filed on this, I'll try to find it out it and
make dependencies.

Comment 13

[rubydoo123]

in the current architecture, we cannot unload xpcom plug-ins

Comment 14

[Peter Lubczynski]

*** Bug 96809 has been marked as a duplicate of this bug. ***

Comment 15

[Patrick Barnes]

It should be common knowledge by now that Java is flawed by design.  It is a
bloated environment designed to obscure the OS from a program: a pseudo-platform
of sorts.  The environment is designed to remain running.  If you want
efficiency, you should be avoiding Java anyway.

Comment 16

[brian]

Ha ha... thanks Patrick. "a pseudo-platform of sorts": remind you of anything
else? ;)

Comment 17

[R.K.Aa.]

*** Bug 166041 has been marked as a duplicate of this bug. ***

Comment 18

[Aleksey Nogin]

Wait, how did this bug morphed from "Java VM processes never close" into "XPCom
Plugins should be unloaded when not in use"??? If I understand correctly, once
bug 102474 is fixed, it should become possible to shut down the JVM process
(_all_ its threads) without completely unloading the plugin.

It is not as important to make sure that everything is unloaded, as long as most
of it is and the resources (memory, /dev/dsp, etc) that were grabbed by JVM are
released.

Comment 19

[Frédéric Buclin]

Comment 10 seems to be a good solution. What is going on with this bug?
Is or will Firefox be able to unload ununsed plugins?

Comment 20

[Boris Zbarsky [:bzbarsky]]

(In reply to comment #19)
> Comment 10 seems to be a good solution. What is going on with this bug?

It's looking for someone to fix it.  Are you volunteering?

> Is or will Firefox be able to unload ununsed plugins?

No, maybe, and it doesn't matter in that order -- this bug is about XPCOM
plugins, not NPAPI plugins.

Comment 21

[:Gavin Sharp [email: [e-mail]]]

*** Bug 282081 has been marked as a duplicate of this bug. ***

Comment 22

[Rob Vaughn]

If the XPCOM module was loaded when needed and then unloaded, it might solve or greatly diminish this problem.

I'm experiencing exactly the same problem, running Firefox 1.5, uTorrent, and
my ADSL connection (actually, the NIC) hangs completely every 10-24 hours.  I
have never gone more than 24 hours a day without a reboot.  This is on Windows
XP with all SPs.  Not running anything else but Firefox and it loses the
network connection - the Network Connection info show the IP address, DNS, etc.
all gone, and traffic slows to a trickle until it dies.

I tried uninstalling Norton Anti-Virus which I found entries as having a probem
with, and used a special utility someone wrote to COMPLETELY remove it, and ran
without for a week and that didn't fix it.

Comment 24

[Benjamin Smedberg]

XPCOM plugins are gone, all hail.