Memory savings with Java 5 and eclipse?

Engines, Libraries and Tools Tools Discussion
#1

Eclipse is a memory hog, especially considering it runs an entirely separate process per workspace. So much so that my poor crappy laptop runs out of RAM if I have two or three workspaces open and try to also check email and surf sites (needed whilst developing!).

Because linux swapping is so utterly utterly crap after a few days I have to reboot the computer to clear out the swap etc if I run like this - else I end up with literally 5-minute waits moving from one workspace to the other (alt-tab) or to my web-browser etc.

BUT…java 5 supposedly has some of the shared-class stuff. So, I’m wondering if this makes any considerable saving with multiple workspaces for eclipse, or whether the saving is negligible…anyone tried it?

For reference, a typical workspace for me takes up 95Mb of RAM (according to linux). By only ever working on a few files at once (the pain!), combined with the fact that it eventually swaps some of that out because I’m not using it, I can steam along OK at around 87Mb usage per workspace. Still, three workspaces blows my entire RAM, and two struggle to co-exist with Mozilla (which has many memory leaks).

#2

I mention that the current Eclipse versions don’t use any Java 1.5 performance boosts. Maybe the 3.0.2 release will change that.
90MB is also the typical workspace size on windows. I hope that it will run smoother when i got the addiditional 512MB Ram next week :slight_smile:

#3

If I may be so bold, I think that if you’re running Eclipse on three different workspaces at once, you may have misinterpreted what the word “workspace” implies! ;D

I don’t think Eclipse has to do anything special to take advantage of class-definition sharing - it “just happens”. So I, too, would be interested to hear whether it works in the real world, and whether the engineers were right to spend so much time on it! Anyone?

#4

[quote]If I may be so bold, I think that if you’re running Eclipse on three different workspaces at once, you may have misinterpreted what the word “workspace” implies! ;D
[/quote]
Interesting point, but no - I’m forced to do this because that’s the way that Eclipse wants you to do it. Eclipse wants to do various things on “all projects in the workspace” by default, and after trying to fight in (with only partial success) eventually I twigged why: An eclipse-workspace is what most people used to working on large projects would call a project (i.e. “one or more tightly related libraries”, or “all the components of a large componentized application”) and that an eclipse-project is what most people would call a single component (i.e. something that they JAR into just one JAR) - e.g. “a single self-contained library”.

Now, I have:

1 a base engine project ( 8 JAR’s) == one workspace
2 a CMS project (4 JAR’s, runs on top of base engine) == another workspace
3 JGF server (1 JAR + N other JARs to add extra content/features later on) == a third workspace

The annoying thing is that I only very occasionally even need to even look at workspace 1 (usually to tweak some code that the CMS project is exercising in new ways, or to refactor something between the CMS and the base engine).

Whilst doing JGFv3, I often need to edit the CMS project (because this project is being brought to production-quality roughly in parallel with JGFv3).

But if I put all in one workspace I get the following problems:

  • workspace has far far too many eclipse-projects in it to be manageable. Far too many open files at once for the navigation to be easy
  • every time you change a base file, it reparses EVERYTHING, and you can end up waiting a long time for the reparse to chain through all those dozens of projects
  • …which is stupid, because the three workspaces are INDEPENDENT projects (in the real world sense) that just happen to link together at runtime.

But, thankfully, by having multiple workspaces I can insulate the various projects from each other.

#5

Yeah, it Just Works. But…the question is: how much saving is there? My suspicion is that you get hit by a mega-nasty side-effect of SWT: because it’s not AWT, it’s not involved in the class-sharing, so the savings are minimal. But… I can’t quite recall how far the java 5 sharing goes - whether it was just core stuff or the whole of rt.jar etc.

So…looking for some experimental results! (And I don’t have a spare PC which I can afford to risk putting java 5 on to check for myself :().

#6

[quote]But if I put all in one workspace I get the following problems:

  • workspace has far far too many eclipse-projects in it to be manageable. Far too many open files at once for the navigation to be easy
  • every time you change a base file, it reparses EVERYTHING, and you can end up waiting a long time for the reparse to chain through all those dozens of projects
  • …which is stupid, because the three workspaces are INDEPENDENT projects (in the real world sense) that just happen to link together at runtime.
    [/quote]
    Interesting. Do you happen to have played with Working Sets? They allow you to defines collections of things that you’re interested in at one time, and may solve part one. (Click the down arrow in the top-right of Package Explorer.) The annoying bit is that the package explorer view will appear collapsed as opposed to how you left it.

Closed projects should be insulated from changes in a dependent project, so that should help with part two. (Right click project, select Close Project.) You can even open or close several projects at once.

Also, if you define dependencies in terms of exported JAR files instead of inter-project dependencies, Eclipse won’t need to rebuild everything until you update the current “exported” API.

Part three isn’t really a separate point, so instead I’ll use this paragraph to mention that if you’re using different Workspace-global settings, you may be scuppered anyway. ;D

#7

[quote]So…looking for some experimental results! (And I don’t have a spare PC which I can afford to risk putting java 5 on to check for myself :().
[/quote]
I’ll see if I can do something tonight - although time, as ever, is short.

Edit: Regrettably, WinXP doesn’t seem to come with any useful memory profiling tools - at all. From the information that Task Manager is feeding me, it looks like every successive JVM instance takes up more RAM than the previous one… ::slight_smile:

#8

[quote]Eclipse is a memory hog, especially considering it runs an entirely separate process per workspace. So much so that my poor crappy laptop runs out of RAM if I have two or three workspaces open and try to also check email and surf sites (needed whilst developing!).
[/quote]
Followup: Perhaps SWT has been coded to share memory anyway (would make sense, given that it’s a native code solution, not java)?

I’m not very good at manipulating “top”, but managed to get the process info displayed for several workspaces at once, and noticed that:

  1. the first started workspace has approx 90Mb / 8Mb / 50Mb
  2. the next one has approx 110Mb / 42Mb / 110Mb

(where x/y/z = “amount of memory process is using” / “amount of memeory process MIGHT be sharing with other processes” / “amount of ACTUAL, non-shared, memory process is exclusively using”)

Top has quite a few problems with this stuff - it’s ability to tell what is shared and what isn’t is known to be often wildly inaccurate - but it would seem to suggest that the second workspace is sharing considerably amounts of memory with the first one?

Then again, the fact that it is claiming to be exclusively using 100% of its memory makes it all a bit uncertain ;).

NB: switching to mozilla to post this reply caused HUGE swapping. When that was over, the second workspace was now: 92Mb / 22Mb / 86Mb. Eclipse has a tendency to ballon and deflate it’s memory usage a LOT (probably generates lots of garbage?).