Re: Memory residence

[shudo at computer dot org]

From: shudo@computer.org
Date: Wed, 08 Jun 2005 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/