7

My Eclipse footprint is steadily increasing from 500MB to >1GB without me doing anything in particular - just running some log heavy programs. Doing a manual GC, closing and reopening projects does not help at all, once it's over 1GB it stays there.

I've run jvisualvm and found out from the heapdump that hundreds of megabytes are char[] representing log output.

I make it a habbit to close all the consoles of stopped processes, so it's not that. Console buffer is set to 1MB (characters). I've closed the console view and reopened it again.

I can paste my particular eclipse.ini but I've tried different GC and memory settings, different JVMs, different Eclipse versions - behavior is still the same.

To me it seems that the logs are getting stuck with a reference somewhere and never get released. Is anyone else having this problem? Is there a setting somewhere to release memory from old console views?

brainwash
  • 690
  • 5
  • 19
  • 1
    Do you have a lot of source files open in the editor at the same time? In my experience closing all unused files releases a lot of memory. – kpentchev Sep 11 '12 at 16:30
  • Eclipse Juno and Helios. I only keep a few files open at a time, it makes no difference. It's just memory that never comes back no matter what I do and close, only a restart of Eclipse restores it. – brainwash Sep 11 '12 at 20:12

2 Answers2

1

While I thought about something smart to write here I found this: How to reduce Eclipse's memory usage? Where the suggestion to disable spellchecking actually made a lot of difference.

So.. here is my own contribution: This might sound strange, but I've also noticed myself having a lot of unused breakpoints makes Eclipse sluggish. Regularly clearing all break points is a sound habit.

This is just a tip related to this, there's an option to show memory and to force an GC from within Eclipse. Under

Preferences>General>Show Heap Status

Community
  • 1
  • 1
Peter
  • 5,556
  • 3
  • 23
  • 38
0

Short answer: heap size is not shrinking, only growing.

Long answer: In the end it seemed like a combination of factors. I'm not completely sure what the JVM default options should be, but my XP machine has the Windows performance optimisation set to 'Server'/'Background applications'. I believe this also causes the JVM to default to the '-server' option instead of the '-client'. The -server option does not allow the heap to shrink.

As far as I've found out, parallelGC does not allow the heap to shrink.

The default values for XX:MaxHeapFreeRatio (70) and XX:MinHeapFreeRatio (30) are pretty lazy in giving up free memory. Setting them to 20/10 will result in a heap size closer to actual usage.

Why is all of this important? Well, if you are developing a desktop application in Java your client might get upset with the ever-increasing memory usage and blame your bad programming. Kind of like what happens with Firefox.

brainwash
  • 690
  • 5
  • 19