Community
Participate
Working Groups
Build ID: I20070517-1700 Steps To Reproduce: 1. c:\tools\eclipse\eclipse.exe -vmargs -Xmx750m More information: It launches if I specify only 500m c:\tools\eclipse\eclipse.exe -vmargs -Xmx500m The M7 build worked with -Xmx750m. Eclipse fails immediately and displays the following: JVM terminated. Exit code=-1 -Xmx750m -XX:MaxPermSize=256m -Djava.class.path=c:\tools\eclipse ... -os win32 -ws win32 -arch x86 -showsplash c:\tools\eclipse ... -launcher c:\tools\eclipse\eclipse.exe -name Eclipse --launcher.library c:\tools\eclipse ... -startup c:\tools\eclipse\plugins ... -vm c:\tools\java\jdk1.5.0_08\bin\..\jre\bin\client\jvm.dll -vmargs -Xmx750m -XX:MaxPermSize=256m -Djava.class.path=c:\tools\eclipse ...
Works for me with I20070517-1700 (RC1). Can you attach a crash stack? It is typically called hs*.log in the directory where eclipse is installed.
Created attachment 68702 [details] Log created executing the command " c:\tools\eclipse\eclipse.exe -data . -vmargs -Xmx750m"
Failures start with -Xmx657m. -Xmx656m works.
Hmmm, I don't know. - Could you try to run with an option "-XX:MaxPermSize=64m" to see if this allows you to run with "-Xmx750m"? [This option will override the new default of "-XX:MaxPermSize=256m" used by the launcher] - How much actual physical free memory do you have just before running Eclipse? How much is left after you start it? A different possibility is related to the msvr*.dll. Looking at the stack: ntdll.dll MSVCR71.dll MSVCR71.dll jvm.dll In the past using incompatible versions of msvcr*.dll was known to cause crashes. Something along the line that if one version of it was using to build JVM and an incompatible version was picked up during the launch time. Sun has this interesting bug about application launch and msvcr71.dll: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6509291
It worked with "-XX:MaxPermSize=64m". I was able to use values up to "-XX:MaxPermSize=162m" before it failed.
Good! And how about free physical memory? You can find this number in the Windows Task manager -> Performance tab -> Physical Memory -> Available. How much free memory is there before and after you launch Eclipse?
Before 1669476 After 1558568
On my computer the magic number is XXMaxPermSize=256 + Xmx948 = 1204. 1205 doesn't start.
For my computer (physical memory available around 1000Mb) the limit is: -Xmx940m with PermSize set to 256 (1196 Mb) -Xmx996m with PermSize set to 200 (1196 Mb) For Brian it seems to be that JVM exists when more than 912Mb is specified as memory maximums for those two pools with the total physical free memory about 1600 Mb. At the same time if I run just "Hellow World" java class I can set those pools to much higher values.
If I run with eclipsec.exe (as opposing to eclipse.exe) from a console window, the following error message shows up in the console: Error occurred during initialization of VM Could not reserve enough space for object heap
The same limit applies to an "application" that only does System.out.println() if the "application" is packaged to run with eclipse launcher. The "pure" java run of the same System.out.println() "application" (java -jar ...) accepts all sane numbers as limits (tried to -Xmx100000m -XX:MaxPermSize=10000m).
Another observation is that if I run that same "application" using eclipse launcher pointing to java.exe ("-vm java.exe"), the limit still exists. The limit is different from the no "-vm java.exe" limit. On my computer it is 1704 Mb in the "-vm" case and 1196 in the no-argument case.
I'm getting much the same results... only an even lower limit. On 1.5 GB of RAM under XP Pro, my limit of max heap + max perm size is 692 MB.
*** Bug 193609 has been marked as a duplicate of this bug. ***
The cause of this was identified as being the jvm's requirement for contiguous memory and some windows dlls being loaded in the middle of the address space leaving the remain segments of free memory too small. bug 195809 moved the default image base for the eclipse dll to be out of the middle, but there are still other libraries there we do not control. You can specify more memory using the java launcher because it is not loading the dlls. The dlls are for displaying the splash screen, we need a way to force the libraries to load at some location other than their default image base.
*** Bug 180212 has been marked as a duplicate of this bug. ***
The suggestion after talking with some VM guys is to try using VirtualAlloc to reserve the memory before loading the windows libraries. This of course requires the exe to be changed to load the graphics libraries dynamically instead of at load time. This is similar to the changes made in bug 201414 for some of the other platforms.
Same here on a 4 GB Windows 2000 computer: I can start Eclipse up to 1354 MB: -vmargs -Xmx1354m for higher values (1355 and up), Eclipse doesn't start with an exit code of -1. Especially for profiling larger server applications, this value can still be too less, so we would need more memory for eclipse. Is there any hope to address this issue in one of the next patches/releases?
i ran into this on winXP/sun java6u6 trying the latest 3.4 milestone (3.4m6a). Both with 1GB and 2GB ram installed the default launcher quit with a popup that did contain the command that launched the vm, but no descriptive error message. After i used -consolelog -debug on the commandline and got 'Could not reserve enough space for object heap', i checked eclipse.ini and the defaults for max memory are 256m permgen and 512m heap which basically is too much to handle for 1GB, but should fit fine into 2GB. To improve the user experience and reduce the number of occurences for this issue i suggest the following: a) lower the default PermGen limit to 128m, which imho is enough for most eclipse users. The few that will run into OOMEs can still set a higher default manually b) give a more descriptive error message if launcher fails, so users won't have to dig for it. c) document the problem on the known issues page and in eclipse help d) use java(w).exe instead of jvm.dll in the launcher e) think about the minimum required ram for a system that should be capable of running eclipse ganymede packages and adopt Xmx accordingly. Imho, 512 is too much for Systems with 'just' 1GB ram, 256 or maybe 384 sound more reasonable to me. e1) instead of absolute values, have the launcher check available memory and use a percentage of that (i know this properbly won't happen)
in my previous comment i didn't explicitly mention the fact that this happened to me in a default installation scenario so i guess this could hit others as well. I'm a bit surprised that it hasn't come up more until now... Can someone confirm that this is a general problem? To check it, i think its sufficient to point to jvm.dll via -vm or eclipse.ini using the default memory sizes (Xms40m Xmx512m PermSize 256m)
Dominik, you are the first person (that I have seen) to report not being able to run with the default memory setting since the original cause of low memory limits was fixed (Bug 195809). Until last week I have been running on a machine with 1.5GB of ram and never had any problems and I routinely run 2-3 instances of eclipse at the same time. It is possible that you have 3rd party libraries loading in the middle of your address space (see bug 195809 comment #2). The best way around this would be to run with -vm javaw.exe. You should raise a bug on the packaging project (https://bugs.eclipse.org/bugs/enter_bug.cgi?product=EPP) about the default values in the ganymede downloads. For the error message, it is the vm that is failing. The launcher does not know why it failed, only that it returned -1.
(In reply to comment #21) > The best way around this would be to run with -vm javaw.exe. so why is jvm.dll used when no -vm argument is given? > You should raise a bug on the packaging project > (https://bugs.eclipse.org/bugs/enter_bug.cgi?product=EPP) about the default > values in the ganymede downloads. done: bug 229152
(In reply to comment #22) > > The best way around this would be to run with -vm javaw.exe. > so why is jvm.dll used when no -vm argument is given? The jvm.dll is used by default because it brings many other advantages and most people are generally not having memory problems with the default values. Some advantages are: - Splash screen coming up sooner. - Eclipse.exe in the process list instead of java.exe - Firewalls: eclipse wants access to the net instead of java - Window management branding issues, especially on windows & mac.
This problem occurs because of the execution of CreateWindow API for the splash display. The Windows system loads two or more DLL into the memory space by executing CreateWindow API. As a result, a consecutive memory space is divided into parts by the loading of DLL. Please display the splash after the execution of JNI_CreateJavaVM (Before the call of main()). I think that I can evade this problem.
In 3.4, the call to CreateWindow can be avoided by not including -showsplash in the eclipse.ini file. In this case, the splash screen will be shown after java starts and Main can read the splash location from the config.ini. It is possible that this could be improved further with changes similar to what was done in bug 201414 for the linux platforms. The dll is linked against some libraries (ie comctl32.lib, gdi32.lib) that we could likely postpone loading until we know we are showing graphics.
I've removed -spashscreen and provide -vm java.exe - did not help. What else could be done? P.S. I've never played with this unless eclipse failed with OutOfMemory too soon. :)
Created attachment 105445 [details] jvm crash log Oops! After returning back comment 26 jvm started to crash - here is the log.
*** Bug 237652 has been marked as a duplicate of this bug. ***
Are there any updates on this? This issue seems to be getting more difficult to work around. For example, under WinXP SP3 32-bit with Eclipse 3.5 and 2 GB RAM, I can reproduce the issue with -Xmx1024m, but not -Xmx768m. Once I hit the limit (whatever it ends up being), removing -showsplash does not help, though I recall it used to. Additionally, changing the JVM binding type between using the .dll and the .exe does not help either, though I also recall it used to. I think the only option I have left is the undesirable option of skipping the Eclipse.exe launcher and starting Java directly by setting the classpath, environment, system properties, and other command-line options. Having the increased memory available in increasingly necessary. Just using a larger distribution package such as the "Eclipse IDE for Java EE Developers" and having a moderately-sized project with a number of JSPs and Java classes quickly results in out-of-memory exceptions and a restart of the IDE required. Please review the priority, severity, milestone, and assignment of this bug accordingly. Thanks!
I found juggling with some of the other parameters can help with increasing the memory accessible by Eclipse: -vmargs -Xms384m -Xmx640m -XX:PermSize=512M -XX:MaxPermSize=512M These arguments work on my Windows 32 bit system with 2 GB memory, and essentially gives Eclipse around 600 MB of real memory and 1100 MB of virtual memory. Hope this helps.
Jevon (or anyone) - please correct me if I'm wrong, but I don't see how comment #30 helps. I had tried playing with this a little, and it actually seemed to have the opposite / worse effect. The permanent generation space is a separately allocated section of memory, to my understanding. While increasing it may be necessary in some cases, it is not the issue here, and increasing it actually reduces the amount of memory available to meet the requirement of what is requested for the heap space by -Xmx.
(In reply to comment #29) > Additionally, changing the JVM binding type between using the .dll and the .exe > does not help either, though I also recall it used to. I think the only option > I have left is the undesirable option of skipping the Eclipse.exe launcher and > starting Java directly by setting the classpath, environment, system > properties, and other command-line options. Changing to use -vm javaw.exe should be equivalent to starting java directly with the full command line. If you are getting memory problems starting this way, I would expect you to also get them starting java directly. If this has gotten worse for you it could be that 3rd party libraries are getting pulled in. See bug 195809 comment #2, if I recall correctly I was seeing dlls related to add-ons for MSN Messenger being pulled in. You can trace the loading of dlls during start up using something like dependency walker: http://www.dependencywalker.com/ Using -nosplash for me did result in fewer libraries being loaded before the jvm.dll was started.
Side note: I've found jconsole to be incredibly useful when debugging memory / permgen issues. After adding '-Dcom.sun.management.jmxremote' to eclipse.ini one can use jconsole (in the bin directory of the JDK) to get detailed infos about the different memory pools including permgen. This is much more detailed that Eclipse's heap monitor.
Created attachment 144128 [details] patch This patch does for windows what bug 201414 did for gtk. (Load the graphics libraries dynamically when needed.) Testing 3.6M1, on Sun 1.6.0_07, on my machine using -Xms40m -XX:MaxPermSize=256m -Xmx??m looking for the maximum value of -Xmx before failing. I get: 3.6M1 : -Xmx1158 3.6M1 removing -showsplash from .ini : -Xmx1162m (not much gain here) 3.6M1 with patch and no -showsplash : -Xmx1250m java -jar : -Xmx1250m This patch achieves the same memory use as using plain java -jar. The key point is delaying loading user32.dll for the splash screen until after the vm has started. This is done by not specifying -showsplash in the eclipse.ini (or passing -nosplash to not show it at all). This patch needs more testing, I have only tried x86 compiled with cygwin. Need to test the normal msvc compiled version, as well as x86_64 (and ia64 if possible). This patch does not affect wpf.
It seems like there are two issues reported in here: 1) The vm actually crashing, as reported by the .log included as attachment. I believe most people reporting on this issue in this thread are not reproducing the crash, but rather the -1 return value. 2) For all vm instance, there is a limit beyond which the -Xmx flag will cause java to fail at startup with a -1 exit code. On one test machine, for instance, with 1.5GB of RAM installed, if I have -Xmx1332m in the eclipse.ini file, it starts fine, and if I put -Xmx1333m, it fails with exit code -1. Using eclipsec.exe, it shows the following message on the console in that case: Error occurred during initialization of VM Could not reserve enough space for object heap Now, if I launch eclipse using java -j plugins\o.e.equinox.launcher.jar instead, I can get up to -Xmx1615m instead before I get the -1 exit code. Is the patch discussed above supposed to address 1) or 2) ? I assume 2), but unfortunately, using the patch on my machine and rebuilding both eclipse.exe and the companion library, it makes no difference whatsoever: eclipse.exe will return -1 at -Xmx1332m. Now, is that a bug (it's certainly an undesirable behavior), and am I missing something here?
This bug is about the -Xmx memory limit (2). The crash (1) from comment #27 seems unrelated and doesn't really belong here. Serge, for the patch to make a difference, you will need to change the eclipse.ini to remove the -showsplash, or add a -nosplash.
(In reply to comment #36) > This bug is about the -Xmx memory limit (2). The crash (1) from comment #27 > seems unrelated and doesn't really belong here. > > Serge, for the patch to make a difference, you will need to change the > eclipse.ini to remove the -showsplash, or add a -nosplash. > Unfortunately, I pass -nosplash (and -showsplash isn't passed), and it still fails at the same limit as before (-Xmx1333m). I used Process Explorer (procexp.exe) to ensure that no user32.dll or gdi32.dll libraries were loaded at startup, by stepping with the debugger: In main(), the libraries loaded are: ctype.nls eclipse.exe kernel32.dll Windows NT BASE API Client DLL Microsoft Corporation 5.1.2600.5781 locale.nls msvcrt.dll Windows NT CRT DLL Microsoft Corporation 7.0.2600.5512 ntdll.dll NT Layer DLL Microsoft Corporation 5.1.2600.5755 sortkey.nls sorttbls.nls unicode.nls Once I get to the loadWin32(), the following libraries are loaded: ADVAPI32.DLL Advanced Windows 32 Base API Microsoft Corporation 5.1.2600.5755 ctype.nls eclipse.exe eclipse_1017a.dll kernel32.dll Windows NT BASE API Client DLL Microsoft Corporation 5.1.2600.5781 locale.nls msvcrt.dll Windows NT CRT DLL Microsoft Corporation 7.0.2600.5512 ntdll.dll NT Layer DLL Microsoft Corporation 5.1.2600.5755 RPCRT4.dll Remote Procedure Call Runtime Microsoft Corporation 5.1.2600.5795 Secur32.dll Security Support Provider Interface Microsoft Corporation 5.1.2600.5834 sortkey.nls sorttbls.nls unicode.nls And exiting loadWin32(), the following libraries are loaded: ADVAPI32.DLL Advanced Windows 32 Base API Microsoft Corporation 5.1.2600.5755 COMCTL32.dll User Experience Controls Library Microsoft Corporation 6.0.2900.5512 ctype.nls eclipse.exe eclipse_1017a.dll GDI32.dll GDI Client DLL Microsoft Corporation 5.1.2600.5698 IMM32.DLL Windows XP IMM32 API Client DLL Microsoft Corporation 5.1.2600.5512 kernel32.dll Windows NT BASE API Client DLL Microsoft Corporation 5.1.2600.5781 locale.nls msvcrt.dll Windows NT CRT DLL Microsoft Corporation 7.0.2600.5512 ntdll.dll NT Layer DLL Microsoft Corporation 5.1.2600.5755 RPCRT4.dll Remote Procedure Call Runtime Microsoft Corporation 5.1.2600.5795 Secur32.dll Security Support Provider Interface Microsoft Corporation 5.1.2600.5834 SHLWAPI.dll Shell Light-weight Utility Library Microsoft Corporation 6.0.2900.5512 sortkey.nls sorttbls.nls unicode.nls USER32.dll Windows XP USER API Client DLL Microsoft Corporation 5.1.2600.5512 VERSION.dll Version Checking and File Installation Libraries Microsoft Corporation 5.1.2600.5512 So it seems that the patch does that it was intended to do: delay the main dlls to when loadWin32() is called, but since loadWin32() is called before the vm is loaded, I don't see what it changes, maybe I'm missing something here.
Also, I tested with 3.4.1: same results, the patch makes no difference in the -Xmx limit to which eclipse.exe will return the -1 exit code.
After some significant changes to the patch, including loading on demand the libraries (as opposed to inside the loadWin32() call), and avoiding calling initWindowSystem() is -nosplash is passed, I was able to make the -Xmx limit go up to 1427m, from 1133m before. That is with or without the -nosplash specified. An improvement, but still below the normal java -Xmx limit on my test machine of 1613m. The problem lies in the fact that some libraries still need to be loaded, to perform calls to GetFileVersionInfoSize(), GetFileVersionInfo() in IsSunVM().
(In reply to comment #37) > So it seems that the patch does that it was intended to do: delay the main > dlls to when loadWin32() is called, but since loadWin32() is called before the > vm is loaded, I don't see what it changes, maybe I'm missing something here. > Serge, the intention is that the loadWin32() function is not called until after the vm is loaded. It is only called from 2 places: initWindowSystem : called when displaying the splash screen, or message box. Not passing -showsplash should delay this until after the vm is started and java Main calls back to show the splash. Passing -nosplash should result in this not being called at all. launchJavaVM: called to fork the vm in a new process, in this case the loadWin32 shouldn't affect the memory since java.exe is being run instead of loading the vm in our memory space through JNI. If the version library is interfering (it didn't for me), that can treated in the same way as the other libraries. To avoid this call "--launcher.XXMaxPermSize" should not be passed. (If you know you are running on sun, then you can replace this with the vm arg -XX:MaxPermSize=).
(In reply to comment #40) > (In reply to comment #37) > > So it seems that the patch does that it was intended to do: delay the main > > dlls to when loadWin32() is called, but since loadWin32() is called before the > > vm is loaded, I don't see what it changes, maybe I'm missing something here. > > > > Serge, the intention is that the loadWin32() function is not called until after > the vm is loaded. > > It is only called from 2 places: > initWindowSystem : called when displaying the splash screen, or message box. > Not passing -showsplash should delay this until after the vm is started and > java Main calls back to show the splash. Passing -nosplash should result in > this not being called at all. > > launchJavaVM: called to fork the vm in a new process, in this case the > loadWin32 shouldn't affect the memory since java.exe is being run instead of > loading the vm in our memory space through JNI. > > If the version library is interfering (it didn't for me), that can treated in > the same way as the other libraries. To avoid this call > "--launcher.XXMaxPermSize" should not be passed. (If you know you are running > on sun, then you can replace this with the vm arg -XX:MaxPermSize=). > Thanks for your reply. Generally speaking, having to avoid to display the splash screen and removing the check for the SunVM seems like that it either removes functionality (the Splash screen) or can cause other launch issue (basically people who were relying on the IsSunVM() being called). Were you considering this patch (and the -nosplash requirement) to be eventually suitable for the official eclipse.exe or only a patch to be applied for users experiencing this issue?
I'm surprised this bug is still open after all this time. The heap-size limit on 32-bit Microsoft Windows is well known[1]. You simply can't fit a 2GiB Java heap plus required native memory into a 2GiB user process space (the kernel takes the other 2GiB, which is why you don't really get 4GiB per process on 32-bit Windows). If you ask for too much, you get denied. There is no magic number that always works or always fails. It depends very heavily on the kernel configuration (e.g. 2GiB/2GiB versus 1GiB/3GiB process-split), which supporting libraries are loaded at which times, and which versions (because they all have slightly different memory requirements). There is nothing Eclipse can do about it, other than capture the failed JVM-launch event and try to notify the user what happened and maybe why it happened. [1] https://stackoverflow.com/questions/1434779/maximum-java-heap-size-of-a-32-bit-jvm-on-a-64-bit-os
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
IMHO this could be closed as WONTFIX.
(In reply to Mauro Molinari from comment #44) > IMHO this could be closed as WONTFIX. I agree.
Default these days is -Xmx2048m so I move this bug to worksforme. Note: this bug is referred to from https://stackoverflow.com/questions/316265/how-can-you-speed-up-eclipse
(In reply to Lars Vogel from comment #46) > Default these days is -Xmx2048m so I move this bug to worksforme. > According to https://www.eclipse.org/eclipse/development/readme_eclipse_4.17.php#mozTocId60052 default is 1GB - not 2GB. Does the readme need an update? > Note: this bug is referred to from > https://stackoverflow.com/questions/316265/how-can-you-speed-up-eclipse
