"The JVM could not be started. The main method may have thrown an exception" error when starting idea.exe
Created on: Dec 9, 2009 10:01 PM by Serge Baranov - Last Modified: Sep 7, 2011 3:23 PM by Serge Baranov
In IntelliJ IDEA 9.0 we've raised the default heap settings to the following values (see idea.exe.vmoptions file):
-Xms128m
-Xmx512m
-XX:MaxPermSize=250m
On some systems the error in subject occurs when trying to run IntelliJ IDEA. It happens because the native idea.exe executable built with the exe4j uses the splash screen which loads a dll (to decode the splash image) in the address space of the process. The jvm.dll loaded after the splash needs to allocate the heap memory in one chunk, however the dll loaded before the jvm.dll can fragment the address space (limited to 2GB for the 32-bit applications) too much and there will be no single chunk of free memory required for the JVM to initialize.
Depending on the other DLLs loaded, applications with DLL hooks and drivers installed on the system, IntelliJ IDEA may be not able to start even with relatively low heap size of 512m.
Workarounds:
- use idea.bat to run IntelliJ IDEA (you need to set IDEA_JDK environment variable pointing to the JDK 1.6 installation first)
- lower heap size in idea.exe.vmoptions to 400m or the value when JVM can be started reliably on your system
- replace idea.exe with the new version attached to this document which doesn't show splash screen and therefore is not affected by this bug
We plan to address this issue in IntelliJ IDEA 9.0.1 release which will be available before the New Year 2010 by disabling the native splash screen in the executable wrapper.
Bonus:
- in the idea.zip file attached to this document you will also find idea64.exe which allows you to run IntelliJ IDEA under 64-bit JDK (don't forget to set IDEA_JDK environment variable to point to your 64-bit JDK 1.6 installation directory). Good thing is that you can delete jre directory under IntelliJ IDEA installation directory to save some disk space. Running under 64-bit JVM allows to use higher heap size (if necessary), however doesn't use memory efficiently (has overhead), add -XX:+UseCompressedOops VM option to save some memory.
Serge Baranov
says
in response to Andy Armstrong:
You don't need to wait, just grab the attached idea.zip and use idea.exe from it instead of the original one.
Andy Armstrong
says:
Sorry I wasn't clear. I'm using the .exe from the zip. I'd just rather be using the real release.
Serge Baranov
says
in response to Frank Meyer:
Absolutely, this idea.exe works fine with IDEA 8.1.4 as well.
Matthew D. Brock
says:
Well, it works well until it crashes without warning (8.1.4, XP x64). And on restart, has to scan the entire JDK directory again.
Serge Baranov
says
in response to Matthew D. Brock:
Try running under JDK 1.6.0_18 released recently. There must be a crash dump in the IDEA_HOME\bin directory. Such dumps may be helpful for Sun engineers to fix the JDK bugs. Could be also a hardware issue such as faulty memory or system overheat.
Matthew D. Brock
says
in response to Serge Baranov:
Upgrading from u17 -> u18 appears to have solved the problem. Thanks!
Omer van Kloeten
says:
After starting idea64.exe, it gets to the point where the statusbar says "Scanning files to index" and then goes to 100% on one of my CPUs indefinitely.
Serge Baranov
says
in response to Omer van Kloeten:
File a bug to tracker with the CPU snapshot and logs attached. If you can't get the CPU snapshot, provide the thread dumps.
Omer van Kloeten
says
in response to Serge Baranov:
Posted and left the details. Thanks for the quick response :-)
Brent Fisher
says:
Beautiful. That seems to work. Ahhhh. (sigh of relief) Now I can use all that extra RAM on my 64bit Window XP PC! Thanks Serge. BTW, I did a search on the jetbrains support page for this but it didn't come up.
Eric Turley
says:
Wow... this is *totally NOT* working for me.
Win Vista Ultimate 32-bit
1. I'm running 9.0.2 - and STILL get this error.
2. Even after replacing the executable (just for the heck of it) - still getting error.
3. I've tried settings of all sorts of combinations from:
-Xms256m
-Xmx1024m
-XX:MaxPermSize=768m
to
-Xms256m
-Xmx2g
-XX:MaxPermSize=1280m
The highest one that works for me is
-Xms256m
-Xmx768m
-XX:MaxPermSize=768m
... which is just not adequate for this project.
Serge Baranov
says
in response to Eric Turley:
Does it help if you run from idea.bat? Note that you may not be able to use such high heap values on the 32-bit system and 32-bit JDK. Address space of the process limited to 2GB on your system must also include other stuff like memory mapped files and the JVM itself thus limiting the effective heap size you can allocate.
Eric Turley
says
in response to Serge Baranov:
I haven't tried running from idea.bat - because I simply don't *want* to - and based on what I've read here, shouldn't need to.
With 4Gigs of ram recognized on my machine, what is the highest Xmx and MaxPermSize that SHOULD run?
Later, I'll try running it from the .bat, tho - just for information.
Serge Baranov
says
in response to Eric Turley:
As you are using 32-bit system, 2GB is the theoretical maximum for the single process memory, minus memory mapped files, minus DLLs injected into the process, minus JVM internal memory, plus random memory fragmentation = ???. It would depend on the particular system configuration, hardware, drivers, other installed applications, etc. In some cases 768m may be the maximum Xmx you can get. There is no reason to set MaxPermSize higher than 256m.
Eric Turley
says
in response to Serge Baranov:
The last project I worked was pretty big. While running the build, it stopped and Idea gave an error, saying that it was out of memory, and that I should increase MaxPermSize. Changing it to 768 (the highest I could get on that system, as well) worked.
I was able to set my Xmx and MaxPermSize higher with 64-bit Win 7 recently (just switched to Vista 32 for other reasons).
But this OS seems to recognize all 4 gigs:
Serge Baranov
says
in response to Eric Turley:
Discussing windows memory management is off-topic.
http://msdn.microsoft.com/en-us/library/aa366778(VS.85).aspx : User-mode virtual address space for each 32-bit process: 2GB. There is nothing we can do to overcome it. You are welcome to continue this discussion at some more appropriate place. If you still think that it's IDEA problem, please contact support.
Kevin Corcoran
says:
I have tried all three workarounds described here against 9.02 and 9.0.3 and none of them worked. Tested against Java 6 update 20/21 on Windows 7 64-bit.
Kevin Corcoran
says
in response to Kevin Corcoran:
After a long struggle, I finally got this to work on 9.0.3 with a 1.6 update 21, using idea.bat with IDEA_JDK pointing at the 64-bit JDK install directory.
Hanno Wiegard
says
in response to Kevin Corcoran:
I also had some trouble starting with the idea64.exe file but finally adding a idea64.exe.vmoptions file (copy of the idea.exe.vmoptions) did the trick.
rick marry
says:
I see this problem in version 9 and now in version 10 eap.
I find it hard to believe that in version 10 eap, this problem has not been completely eliminated without work arounds.
Jetbrains is better than that, so I must be wrong. Please tell me I'm wrong.
Serge Baranov
says
in response to rick marry:
Rick, the problem from this FAQ doesn't apply to IDEA 9.0.3 and IDEA 10 EAPs. Memory fragmentation problem and inability to use large heap on 32-bit JVM is OS and Java limitation and has nothing to do with IDEA.
If you think that there is some problem specific to IDEA, please file a bug to YouTrack with the steps to reproduce and describe why you think that it's IDEA problem and not OS/Java limitation.
Thank you for this fix! This problem has been bugging me for a while now (both in 8.1.4 and now in 9.0), so it is great to have it solved. I can't wait for 9.0.1.