Reduce SQLDeveloper memory footprint with JDK 1.7

Question

Hi!
Some time ago in another thread (Re: Memory problems with Oracle sql developer there was a suggestion to try the new Garbage-First Garbage Collector. which should be production in JDK 1.7.
I use SQLDeveloper with JDK 1.7 on 64bit Linux with good results:
- everything feels faster, snappier
- fonts rendering is different, but it is OK
- the bugs noted in other threads are not a showstopper for me (the connections pane not showing up on startup, not being able to scroll more than 1 OCI array size of records in results grid)
In the above mentioned thread there is a suggestion that the new garbage collector should improve memory footprint of SQLDeveloper, however, this is not my experience, since it behaves pretty much the same as with JDK 1.6 (resident size between 700 and 900 MB).
Do I need to use these opotions (as per reffering thread) to enable the new garbage collector (see below) or is it switched on by default in JDK 1.7? The reduced memory footprint would be very welcomed, because I use Oracle Warehouse Builder at the same time (also a java app) and there is always much pressure on memory.
AddVMOption -XX:+UnlockExperimentalVMOptions
AddVMOption -XX:+UseG1GC
AddVMOption -XX:+G1YoungGenSize=25m
AddVMOption -XX:+G1ParallelRSetUpdatingEnabled
AddVMOption -XX:+G1ParallelRSetScanningEnabled
Thanx
Aleksander

Answer 1

Hi Aleksander,
Glad to hear of your good report on Java 7's HotSpot VM regarding performance -- it has various enhancements, of which the new garbage collector is just one. In terms of interpreting memory footprints, take a look at:
http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html#generation_sizing
Note the diagram indicates total heap size does not include the permanent generation memory. Xmx limits the heap size (the young and tenured generation). MaxPermSize limits class and method metadata plus static variable content. (Apparently starting back in Java 5 there are even some cases where the permanent generation space can be shared by multiple VM instances to improve start-up time and reduce memory usage.) These two limits control distinct, non-overlapping areas of memory.
When monitoring a Java application's heap consumption with a profiling tool, I doubt the reported usage will exceed the Xmx limit by much. Monitoring with Windows Task Manager, however, can be a bit misleading. I have read several critiques in years past on how Task Manager reports program memory consumption. "Mem Usage" is actually the working set size. "VM Size" is program private memory rather than the true virtual size. And who knows how it tracks the Java VM's permanent generation size. Will it depend on whether it is shared or not?
So I cannot really recommend any additional parameters to you. Just trust in the Xmx setting and hope that SQL Developer keeps any memory leaks to a minimum.
Hope this helps,
Gary