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)

Product:
Core Graveyard
Component:
Java: OJI
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
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.
WFM Build 2002071119 PC/Linux Java plugin 1.4.0-b92
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?
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.
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!
-> 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
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).
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!
I noticed that killing java_vm results in a Broken Pipe message. At the very least, Moz could gracefully recover from this.
--->OJI
Assignee: joe.chou → joshua.xia
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
QA Contact: petersen → dsirnapalli
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
->kyle
Assignee: joshua.xia → kyle.yuan
*** This bug has been marked as a duplicate of 123191 ***
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → DUPLICATE
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Assignee: yuanyi21 → pete.zha
Status: REOPENED → NEW
mass reassign to Alfred
Assignee: zhayupeng → alfred.peng
QA Contact: dsirnapalli → java.oji
Hardware: PC → All
(In reply to comment #10) > ... same as Internet Explorer, at the least. When you time to close?
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.
URL: http://www.dur.ac.uk/estates/accommod...
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!
(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
The latest Java Plugins for Firefox has been moved away from OJI as I know. CC Kenneth for further investigation.
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.
(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/
(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
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.