Submitted On 16-FEB-2006
darrinps
I'm at a loss to understand the logic in marking this as "Will not fix" and your assertion about "running any java probram...and experience the exact same behavior" is incorrect. I often run Java applications set to -Xmx1024M with no problem at all.
The Jave users NEED to be able to set their memory higher some times. I have a Java applet using Java3D that NEEDS more than 128M and so do many people (check your own forums).
The "Will not fix" conclusion must not be allowed to stand.
Submitted On 17-FEB-2006
kymtbr
This is unacceptable and needs to be addressed. The risks involved in running out of memory should be the responsibility of the application. Does this build of the JVM always require half of system memory, no matter how much is available. What if there is 10GB available? The JVM should not limit my application to half of the system memory for no good reason. It should use what it needs and leave the rest to the application. This workaround must not stand.
Submitted On 20-FEB-2006
giles7777
This bug has been closed incorrectly. The original report stated the user specified 750 megs of ram. This is nowhere near the JVM limit of memory. If this bug is reproducible then its a major issue for applets.
Submitted On 23-FEB-2006
JohnWMuir
We have also experienced this problem when trying to get Tomcat to use more of the available memory on several servers. More than ca. 50% of available memory seems to be the limit. This really won't do ;-(
Submitted On 27-FEB-2006
darrinps
It looks like the > 1/2 memory theory may not hold. We have two machines that experience this with the -Xmx setting far below 1/2 of the available memory. On one machine with 1 gig, a setting of -Xmx128M -Xmx256M will cause this problem. On a second machine with 768M of memory, the same setting causes it as well, but at least six other machines we have with between 512M and 1G work just fine with this setting.
This bug must not be allowed to stay closed. The "work around" given is completely bogus (specify a smaller memory size). Well, what if you NEED more memory?
Submitted On 01-MAR-2006
jon999
I'd like to understand what the correct solution is for this problem.
There seem to be different situations.
1) User knows that a heap of NNN is needed to run the application
and specifies -XmxNNN. Application will eventually fail if NNN is
not provided.
2) User knows that a heap of NNN is needed to run the application
well. Application will run with less than NNN but not necessarily
perform well.
3) User knows that a heap of NNN is sufficient to run the application
well but it may perform safisfactorily with a smaller heap.
For 1) it seems like it is better if the VM fails fast since it is going to
fail eventually. Don't waste time getting to the failure.
For 2) it's difficult for the VM to tell what level of performance is
satisfactory so should the VM fail fast or start with whatever
memory it can reserve.
For 3) the VM should start with whatever memory it can reserve.
Are the proposed behavior the right behavior? What about
2)? Are there more cases? I think that some command line
flag would be needed so the VM could distinguish between
1) and 3). I think the default value of such a command line
flag should be to interpret a -Xmx as in 1) for compatibility with
current releases.
Submitted On 08-MAY-2007
I receive the exact same error in the following settings on a machine with 4 GB of Ram. I have tried to set
-Xmx to: 512m, 256m and 128m; however the exact same problem occurrs. I am running Java 1.6 on Vista with IE 7. If I remove the parameter completely the applet will load; however, due to the memory requirements it does not run properly.
Submitted On 09-MAY-2007
cforster
Guys, this sort of thing has been going on for Java from Sun since inception. There is little/no regard for "user experience" issues in running applets of any significance. Numerous times over the years Sun has been asked for this & other plugin enhancements necessary to deploy robust applets using it. They have, as a rule, screwed up.
Often, they respond like "Have the user use Control Panel & type in -XmxNNNm...." "Have the user import the certificate manually using keystore...", "Have them uninstall ver 1.X.X of their JRE & reinstall.." and don't get me started on modal dialogs...
Its sad because Java on the client had a lot of potential.
Best you can do if you want to use Java on the client is head over the Java Web Start or some 3rd party distro-as-application product.
Submitted On 23-MAY-2007
NO NEED TO BE A JERK...
hey thanks for telling us whats wrong, why dont you tell me how to fix it! I don't care how a car is made, JUST TELL ME HOW TO DRIVE IT!
Submitted On 11-JUL-2007
anilsaxena2
This is ridiculous, why this is will not fix status ?
Submitted On 13-JUL-2007
sunnychangs
If you are running into problems with process memory space for Windows XP SP2, you might want to install this hotfix 894472
http://support.microsoft.com/kb/894472/en-us
Also see this blog: http://www-03.ibm.com/developerworks/blogs/page/gbowerman?entry=dll_hell
Submitted On 30-SEP-2007
Galen1967
Marking this as "Well not fix" is entirely unacceptable! 96M (the apparent default for 1.6) is entirely too small for today's applications.
Asking our customers to "fiddle" with their control panel is not unlike asking a high schooler to build a space shuttle. It's just not going to happen.
I understand that it's a bug in Windows that is causing this but to just chuck it aside and say, "not out problem," is bogus!
Submitted On 16-OCT-2007
I agree with the previous comments. I'm developing a panorama viewer that needs to decompress and display multi- megabyte images. OutOfMemoryError's are constantly being reported by people trying to view the images.
Their complaints constantly point out that Flash and other plugins don't have memory problems and when it is suggested that they have to configure the JVM via the Java Control Panel their reaction range from incredulous to hostile.
Because of this one flaw in the engineering of the JRE, many, many people have written off Java as a vehicle for large panoramic image delivery.
I've invested the last ten years of my life developing my Java programming skills and what do I get from SUN -- a knife in my back and excuses as to why the obvious need for more reliable memory allocation cannot be addressed.
UNACCEPTABLE!
Ken Warner
pancyl.com
Submitted On 31-OCT-2007
tomw2
Well, after 12 years of developing applets in Java, I'm now throwing in the towel and heading for ActionScript. Sun's attitude about this is short-sighted, to say the least. This is a "killer" -- end users should be able to use more than 128M or 256M...and NOT have to configure it themselves! Good job in convincing people that Java is not meant for running applets inside a browser!
Submitted On 13-NOV-2007
How could you mark it "Will Not Fix", who hell this guys is ?
Submitted On 27-NOV-2007
Well, partially in response to the delicious:
"NO NEED TO BE A JERK..."
apparent reply to my comment on this bug, I'll be posting an over-bearing hack/work-around for it to a site as its > the 4000 char limit of these comments. Code will require a signed applet w/full rights.
BTW, my comment was borne of having tried and succeeded at developing & supporting a large commercial client-side Java applet/application since 1999. Just suggesting you research things before betting your app or company on this technology.
Submitted On 03-DEC-2007
As I said above, I posted workaround code here:
http://www.dreamincode.net/code/snippet1490.htm
"Java Plugin Signed Applet code" - Use at your own risk blah, blah, blah. If you have signed applet failing for heap under JPI, this should help.
Submitted On 01-FEB-2008
sergen
several Java Virtual Machines running in the same process
Submitted On 09-SEP-2008
Is this problem now fixed and part of the standard java 1.6 ?
Submitted On 09-SEP-2008
It this problem fix and integrated into java 1.6 at this point ?
PLEASE NOTE: JDK6 is formerly known as Project Mustang
|
