Eclipse/JVM fails to start due to lack of memory

Lately, when starting Eclipse, the JVM has failed to start.  A reboot of the system usually fixed the problem.  Until yesterday.  So I had to dig in and solve this problem.

I wanted to share my experiences with debugging this issue.

Added Note: This is not the bug by which Eclipse running under java 1.6u21 fails to pass the permgen size on to the JVM.  If you are running java 1.6u21 with Eclipse, don’t.

Determine why eclipse.exe is crashing with “-debug”

I edited my eclipse.ini and added the -debug option:


Then I ran eclipse.exe from the command-line, hoping to get a bit more information:

$ ./eclipse.exe
Error occurred during initialization of VM
Could not reserve enough space for object heap

Now that’s a clear error message!

I need lots of memory

You may have noticed some pretty large memory numbers in the eclipse.ini.  When Eclipse starts the JVM, it will allocate a little more than 1.2Gb (752M heap + 512M permgen).

I have many large C++ and JDT projects in my workspace.  I run classic Eclipse + CDT + svn plugins.  At one point I was having some memory issues and I blindly bumped up max heap and permgen.  This worked but I may have over-compensated by making them a bit too big.

So it’s memory.  Why did it used to work?  And how to debug it?

StackOverflow and vmmap

I found some useful information from Roland Illig on StackOverflow.  The JVM allocates a contiguous block of memory for its heap.  And a DLL with an improper base address could chop up memory such that I can no longer get that nice large chunk of memory.  Roland mentioned using the Microsoft SysInternals tool vmmap.exe to debug.

First I tweaked eclipse.ini, setting the highest possible max memory setting under which Eclipse would successfully start.   It turns out that this was 660Mb in my case.

Then I fired up vmmap.exe from SysInternals.  I selected eclipse.exe, and a memory map appeared.

I looked for a large segment of (yellow) Private Data.  I found one that was 1.2Gb, as expected.

Under Options, I turned on “Show Free Regions” so I could see any free regions.

Then I looked shortly after my Private Data for any Purple “Image” entries.  These are DLLs.  I noticed that there were 3 DLLs between my large allocation and about 200Mb of memory.  The DLLs had base addresses of 5ad70000, 5b860000, and 5d090000.


Now I just need to map the base addresses back to the DLLs.

By running listdlls.exe from SysInternals, I got a dump of all the DLLs currently running on my system, including their base addresses.  A quick search of this file dump revealed that the errant DLLs are uxtheme.dll, netapi32.dll, and comctl32.dll.

Solution: Rebase or Tune eclipse.ini

It turns out that on XP, these DLLs were rebased too low in XP SP2. One solution is to rebase these files to a more suitable address space.  Beware: this requires great care and knowledge.  I don’t really care to mess around with these unless I have to.

A safer approach is to tune my eclipse.ini settings to a more appropriate max heap size and permgen space.  I used jdk/bin/jconsole to attach to my eclipse process.  I determine I was using about 90M of permgen space.  So I have pared back my permgen space to 128Mb in eclipse.ini and things are working great again.  I will fire up jconsole again after Eclipse has been running for a couple days to determine if these values are OK.


7 comments so far

  1. Maarten Meijer on

    Are you sure this is different from this:
    widely covered in the blogosphere and twitter?

    • Scott Kellicker on

      Absolutely sure — I’m using an earlier Java version.

      I will mention the java 1.6u21 bug above.

  2. EclipseUser on

    has anyone tried to rebase the dlls ? is it ok to do ?

    • Scott Kellicker on

      I have not, although I have successfully rebased DLLs before.

      FYI, Microsoft talks about this specific problem here and here. They provide a hotfix but not for Windows XP.

      A good article on rebasing DLLS :“Need for Rebasing a DLL”, Sangoi.
      Microsoft’s support site has several threads related to this.

  3. Andrew Niefer on

    The relevant eclipse bug is

    The strategy there was to try and avoid loading shared libraries until after the vm has reserved its memory althouh the patch for that was never actually released.

    • Scott Kellicker on

      Andrew, thanks for this info.

      In my case, it was the poorly based Microsoft DLLS. But it looks like the Eclipse launching process is also detrimental to grabbing a big chunk of contiguous memory for the JVM.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: