Memory residence

Wed Jun 8 08:13:00 GMT 2005

From: Tom Tromey <tromey@redhat.com>
> Andrew> You've got to be very suspicious of these simple numbers.
> [ reasons ]
>> I agree. But at the same it would be useful to know where the memory
> is going. How effective would it be to reduce our footprint in
> various ways? What are these ways anyway? It would also be very
> interesting to see numbers that show the benefits (or lack thereof) of
> shared libraries. What happens to the system as a whole when you run
> 5 copies of eclipse?

I tried investigating effects of shared libraries by looking at
/proc/<proc ID>/statm. It shows the number of shared pages in
addition to toral program size and resident set size. We expect that
all shared pages are shared between all Eclipse instances at most.
The PC runs Linux 2.6.11, GCJ 4.0.0, Sun JDK 1.5.0_03, Sun JDK
1.4.2_08 and IBM JDK 1.4.2 SR1a. The version of Eclipse is 3.1M7 this
time. GCJ and Eclipse are RPM packages in the current development tree:
gcc-java-4.0.0-11 and eclipse-{jdt,ecj,platform}-3.1.0_fc-0.M7.8.
While 10 instances of Eclipse ran, I looked at numbers of 10 instances
and average them. No page has not been forced out of memory during
the experiment.
 size resident share resident - share (MB = 1024^2 byte)
 GCJ 4.0 252.4 124.9 29.7 95.2
 Sun 1.5.0 493.5 105.5 53.9 51.6
 Sun 1.4.2 445.0 72.3 25.9 46.5
 IBM 1.4.2 337.9 96.8 8.7 88.1
My understanding is that the number 'resident' shows actual occupied
memory and 'share' means the amount of memory which is possible to be
shared between processes. Then, 'resident - share' indicates least
memory consumption per process.
I guess Sun has been working on this area in which they reduced memory
consumption and the result looks good. There will be much room for GCJ.
 Kazuyuki Shudo	shudo@computer.org	http://www.shudo.net/