Memory residence

Wed Jun 8 18:06:00 GMT 2005

From: shudo@computer.org
Date: 2005年6月08日 15:51:12 +0900 (JST)
> > 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.

This interpretation of /proc/<proc ID>/statm was not correct.
My conclusion in this posting was that GCJ 4.0 is not good at
sharing memory, but it is not certain now.
> 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

I studied source code of Linux kernel 2.6.11 and found that
the number 'share' in /proc/<proc ID>/statm is calculated
by this expression: rss - anon_rss where 'rss' and 'anon_rss' are
members of the struct mm_struct (defined in linux/include/linux/sched.h).
The 'anon_rss' member means the number of anonymous pages, which
includes mmaped files with the MAP_PRIVATE flag. Shared libraries
(.so) are usually mmaped with the MAP_PRIVATE flag and then the number
'share' excludes the shared libraries even though they can be shared
between processes. The 'share' seems to mean mmaped files with the
MAP_SHARED flag, not possible shared memory.
Let me apologize for the incorrect evaluation.
We have to look for other ways to investigate it further.
 Kazuyuki Shudo	shudo@computer.org	http://www.shudo.net/