Archive for the ‘Eclipse Tips’ Category

Tip: Eclipse Slowness/Locking when “Installing Software”

This may fall into the category of something everyone else already knows and I discovered it today.

I had an experience today when trying to install the PDE Visualization component (Update site) into Eclipse 3.6.

P2 just stayed at 5% complete.  I waited.  Made a coffee.  Waited some more.  It never progressed in 15 minutes.

Thinking I had some odd combination of dependencies and P2 was choking on resolving them, I tried to install another component.  Same result.

Then I noticed the checkbox at the bottom: “Contact all update sites during install…”.   I tried to install with this unchecked, and it quickly told me that the PDE Visualization component required draw2d.  So i”Contact All” must be checked to pull dependencies from Eclipse update site.

Hmm, I wonder how many update sites it’s trying to contact?  So I clicked on “Available Update Sites” at the top of the page, and there were 50 or so sites.  Over 20 of them were checked.  Some I knew were unreachable because they were on my corporate network and I wasn’t connected.

So I cleaned up my list of update sites.  Removed those I didn’t need, and most importantly unchecked those that I didn’t want to connect to on a regular basis.  I had only 4 checked when I tried it again.  Fast install.  Problem Solved!

Why did I have so many?  I think its because when I migrated from Eclipse 3.5 to 3.6, I exported my update sites and re-imported them into Eclipse 3.6.

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.

Debugging Eclipse UI layouts with Picasso

I always seem to spend too much time dinking around with UI layouts.  In fact, today I’ve been fighting an odd problem where I had a bunch of extra space in a dialog between two other elements.  I had spent excessive time trying things, over and over again, with no success.  That’s usually a sign to take a step back from the keyboard.

I vaguely remembered there was a tool that painted each composite in the UI a different color.  I Googled and found Simon Archer and Chris Aniszczyk’s Picasso tool.  Picasso is found in the PDE incubator source code (unfortunately it doesn’t get full billing on the PDE incubator page).

I ran my app with Picasso enabled, and clearly saw that something was amiss between my text and my table.  I hovered over the lime green box and was able to get a large screen of useful information (not shown): what the element is, its parentage, layout, etc.  I was able to quickly fix my mistake.

How to use:

  • Import the project into your workspace from the PDE incubator repository.
  • In your run config:
    • Plug-ins: add org.eclipse.pde.picasso.
    • Tracing: enable tracing and turn on org.eclipse.pde.picasso.
  • Start your app.

Essential Plugin: Platform ‘Core Tools’

I wanted to mention another Essential Eclipse Plug-in: the Eclipse Platform Team’s ‘Core Tools’.  I consider it essential to my work based on its inclusion of a single tool: “Find Unreferenced Members”.

Armed with this tool and some unit tests, you can really clean up some code.

Plug-in developers are the primary audience for ‘Core Tools’.  It contributes tools for validating plug-ins/class loading and Eclipse metadata browsing.  You can find more info on its capabilities here:

The essential tool to any Java developer is “Find Unreferenced Members”.

  • Right click on a project, package, or file.
  • Select “Find Unreferenced Members”.
  • A Search view appears with member candidates for removal.
  • Note the matches are only a good set of candidates.  The tool analyzes the Java code in your workspace to determine unused members.  There may be false candidates.  For example, a no-arg constructor might be unreferenced, but as any plug-in developer knows, it’s required if the class is instantiated via plug-in.

The update site is here:

Update: It’s now here:

Deadlock Debugging in Eclipse

My Eclipse-based product dead-locked this morning.

If I had launched from my Eclipse dev environment, I could use the debugger to show me the threads and locks that are giving me trouble.  Darin Swanson has the best explanation of this.

If I had started the product with “-debug -consoleLog‘ or with java.exe instead of javaw.exe, I could have hit ctrl-Break (Windows) to get a thread dump.

But I had started the product from the install bundle, so didn’t have these options.  I also didn’t think the deadlock would necessarily reproduce if I re-ran the product.  A little research showed I had more tools at my disposal than I originally realized.


If I had started the product with the Java 6 (or with Java 1.5 using the VM option), I could use jconsole to attach to my process.  Besides the stack trace, this allows all kinds of interesting monitoring.

To use the tool, you’ll need the process ID.  You can use the task manager on Windows or the  JDK tool jps to get the list of Java process IDs.

The JDK tool jstack works great to just get a quick stack dump from the command-line.  Again, you’ll need the process ID.

I need to spend some time exploring the JMX tools.  Some cool and useful stuff in here.


Another option is Send Signal, a nice program that send the Ctrl-Break signal to your Java process.


Much of the information new to me came from these 2 excellent resources.  Both pages have  other ways to get stack traces, including on *nix, and other useful debugging tips.

Sequence Diagram Tool for Eclipse (part 2)

Many people sent me recommendations for an Eclipse-based UML Sequence Diagram tool.  Thank you all.

I’m going to take a look at some of these in more detail to see if one of them solves the problem  I identfied in the previous post.  I will report back what I find.

So far, the best ‘quick and dirty’ tool for creating sequence diagrams is not Eclipse based.  It’s web based.

It’s called  WebSequenceDiagrams.  Its input is a simple and clear language:

And it generates a usable sequence diagram.  Perfect for explaining how some key interactions in the system work.

This is obviously a very simple example, but I’ve quickly ‘drawn’ diagrams with 12+ objects and 50+ sequences.  Moving back and forth between the JDT/CDT, a text editor and a browser is a bit of a pain.  But its still quicker than anything else I have tried before.