Closed
Bug 156994
Opened 23 years ago
Closed 16 years ago
Java uses lot of memory which is never freed
Categories
(Core Graveyard :: Java: OJI, defect)
Core Graveyard
Java: OJI
Tracking
(Not tracked)
VERIFIED
INVALID
People
(Reporter: mozilla, Assigned: alfred.peng)
References
Details
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529
BuildID: 2002052918
(Sorry, if this is again a dupe, but I did look for it first!)
I am using Java plugin version 1.4.0_01-b03.
Reproducible: Always
Steps to Reproduce:
1. Goto a page with a Java applet (e.g. above URL, although that is an
extreme example...)
2. use some something to check RAM usage (e.g. top on Linux)
3. see java_vm climb to 155MB/26MB (DSIZE/RSS) usage, 135MB/27MB when
all applets are fully loaded
4. go to some other page, java_vm still uses 109MB/27MB
5. close the tab or window, where the Java stuff was displayed, java_vm still
uses 109MB/27MB
Actual Results: The memory used by Java and/or the applet is never freed.
Expected Results: The Java VM should be terminated after leaving a page with a
Java applet, or there should be a different way to get rid of the java_vm
overhead without restarting Mozilla.
Comment 1•23 years ago
|
||
WFM Build 2002071119 PC/Linux Java plugin 1.4.0-b92
Reporter | ||
Comment 2•23 years ago
|
||
What WFY? Is the memory freed? If so, how much does java_vm use after leaving
the page? Or is java_vm stopped afterwards? Is there a changelog for the Java VM?
Comment 3•23 years ago
|
||
Still happens on build 2002091014 on Windows 2000 with Java Plug-in 1.4.0_02.
Start Mozilla. Go to my.yahoo.com. mozilla.exe memory use is ~24 MB.
Then load a java app by going to
http://www.crh.noaa.gov/radar/loop/DS.p19r0/si.kmpx.shtml
mozilla.exe memory use is now 47 mb.
Move to another page without embedded Java content. mozilla.exe never gets smaller.
Reporter | ||
Comment 4•23 years ago
|
||
I tried that procedure with 1.2beta release on Linux with Java Plugin 1.4.1_01-b01:
mozilla java_vm
SIZE RSS SIZE RSS
After start 27108 26M - -
my.yahoo.com 28684 28M - -
http://www.crh.noaa.gov/radar/loop/DS.p19r0/si.kmpx.shtml
29120 28M 32200 31M
my.yahoo.com (again) 29408 28M 32228 31M
This size of the java_vm process is just too much even on my 256MB machine
to be wasted until I close Mozilla!
Comment 5•23 years ago
|
||
-> OJI. Java-implemented plugins is for plugins written in java, not the java
plugin.
I'm not clear that this is mozilla's responsibility. Mozilla is just calling
into the plugin; the plugin is the one that starts up a vm and never shuts it
down. Is the behavior different with other web browsers?
Assignee: idk → joe.chou
Component: Java-Implemented Plugins → OJI
QA Contact: avm → petersen
Reporter | ||
Comment 6•23 years ago
|
||
As this bug is assigned to someone at Sun I hoped that they could get the plugin
fixed. If someone tells me a more promising way of reporting this plugin bug to
Sun I would be happy to report it there (too).
Comment 7•22 years ago
|
||
Shouldn't the OS be changed to ALL, since #3 mentions Win2k.
Why is this still unconfirmed?
I have seen this problem (on Linux) with a number of JDKs (1.3, 1.4.1, blackdown
1.4.1), and a number of versions of mozilla (at least from 1.1), if not earlier.
It also occurs in Firebird 0.6, not surprisingly.
I would suggest increasing the severity of this bug: my sound card can play only
sound at a time, and if Java opens /dev/dsp, I need to quit Mozilla before sound
becomes usable again. As a result, I have to go back and forth between
enabling/disabling the plugin. This is a huge nuisance.
Another note of interest: killing the java_vm processes also terminates Mozilla.
This indicates to me either that
a) They are Mozilla's threads, in which case it should be able to kill them.
b) Mozilla waits on one of the jvm processes (and so should be able to kill it)
Also, this is a serious stability issue -- if someone can crash Mozilla by
crashing JVM, I do not want to be using the plugin.
Joe Chou, as you are at Sun, I believe it is in the company's interest to
contribute towards fixing this problem; it has a small, but certainly
detrimental effect on the adoption of Java as a web platform. As Mozilla gains
momentum, the impact of this bug will become bigger. Thanks!
Comment 8•22 years ago
|
||
I noticed that killing java_vm results in a Broken Pipe message. At the very
least, Moz could gracefully recover from this.
Comment 9•22 years ago
|
||
--->OJI
Assignee: joe.chou → joshua.xia
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
QA Contact: petersen → dsirnapalli
Comment 10•22 years ago
|
||
In fact, this behavior is the same as Internet Explorer, at the least. When you
open a page, the browser initializes the JVM. The browser then maintains that
JVM instance. So, this seems to be an RFE to have mozilla release the JVM when
it's not being actively used.
joshua.xia -- Is this a WONTFIX, or is it something that should be considered?
If it should be considered, we should probably change the summary to reflect
what it is and what should happen.
-M
Comment 12•21 years ago
|
||
*** This bug has been marked as a duplicate of 123191 ***
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → DUPLICATE
![]() |
||
Updated•21 years ago
|
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Updated•18 years ago
|
QA Contact: dsirnapalli → java.oji
Hardware: PC → All
Comment 14•16 years ago
|
||
(In reply to comment #10)
> ... same as Internet Explorer, at the least. When you
time to close?
Reporter | ||
Comment 15•16 years ago
|
||
Why, this is as relevant as it has been. I just looked up what processes are running, and I discovered that there was a Java process (probably because I used an applet once 3 days ago) that was consuming 1.3 GB of RAM.
Reporter | ||
Comment 16•16 years ago
|
||
Hmm, well, I looked into the wrong columns of top, it was really using ~80 MB of resident memory (RES), only VIRT and DATA and SWAP showed ~1.3 GB. But still, 80 MB of resident memory for the lifetime of a browser process is a lot!
Comment 17•16 years ago
|
||
(In reply to comment #15)
> Why, this is as relevant as it has been.
because there has been no analysis here in 6 years, including none by Alfred nor anyone at Sun.
because in that time period no one else believes this is FF's problem.
closed bug examples: bug 165042, bug 400260
Assignee | ||
Comment 18•16 years ago
|
||
The latest Java Plugins for Firefox has been moved away from OJI as I know. CC Kenneth for further investigation.
Comment 19•16 years ago
|
||
The new Java Plug-In introduced in Java SE 6 Update 10 should conclusively solve this problem. Applets are no longer executed in a JVM embedded within the browser process, but in one or more attached JVM instances. These attached JVMs shut down automatically after an idle period.
Comment 20•16 years ago
|
||
(In reply to comment #19)
> The new Java Plug-In introduced in Java SE 6 Update 10 should conclusively
> solve this problem. Applets are no longer executed in a JVM embedded within the
> browser process, but in one or more attached JVM instances. These attached JVMs
> shut down automatically after an idle period.
I second this. I recently installed the latest plugin, Java SE 6 Update 12, and I no longer see this bug in Vista. I had been experiencing it just a week ago, and thought I had the latest plugin, but it doesn't look like I did. For those experiencing this bug, please install the latest Java plugin, and then get back to us.
http://www.java.com/en/download/
Reporter | ||
Comment 22•16 years ago
|
||
(In reply to comment #19)
> The new Java Plug-In introduced in Java SE 6 Update 10 should conclusively
> solve this problem. Applets are no longer executed in a JVM embedded within the
> browser process, but in one or more attached JVM instances. These attached JVMs
> shut down automatically after an idle period.
I installed sun-jre-bin-1.6.0.12 on my Gentoo Linux system and indeed they seem to shut down after about 60s of not having the page with the plugin referenced any more. Great, thanks guys! I'm sure this makes many people happy. :-)
(So because this was apparently solved in an the Sun Java plugin and didn't require Mozilla source code changes, I'm resolving this invalid.)
Status: NEW → RESOLVED
Closed: 21 years ago → 16 years ago
Resolution: --- → INVALID
Updated•16 years ago
|
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•