1 |
On Thursday 11 January 2007 14:26, "b.n." <brullonulla@×××××.com> wrote |
2 |
about 'Re: [gentoo-desktop] CD player recommendations ??': |
3 |
> Uwe Thiem ha scritto: |
4 |
> > On 11 January 2007 10:38, JT Justman wrote: |
5 |
> >> b.n. wrote: |
6 |
> >>> I wasn't aware of this, I must confess. Is there any way to prevent |
7 |
> >>> it, so that when you close the app, it cleans the libs from memory? |
8 |
> >> Not sure how the cleanup works, but these things will just get paged |
9 |
> >> off to swap if you aren't using them. I wouldn't worry about it |
10 |
> >> unless swap is at a premium. |
11 |
> > As soon as a library isn't used by any application any more, the |
12 |
> > memory it occupies is freed. Of course, it might still be cached - but |
13 |
> > that doesn't hurt at all. |
14 |
> Now, who is right? :) |
15 |
|
16 |
At dynamically-linked binary startup, or in response to a dlopen call, a |
17 |
library will be mmap()ed into process memory space. This does not |
18 |
necessarily load the library from disk, although it would indicate to the |
19 |
I/O scheduler that operations are about to happen to/from that disk space. |
20 |
Most of the library will be mapped read-only and thus shared. Any pages |
21 |
that the library uses to keep state, will be mapped copy-on-write (and |
22 |
generally noexec). The symbol table will also need to be read, which will |
23 |
cause some reads from disk unless that area of the library is already |
24 |
cached. As pages containing functions or data are needed and not found in |
25 |
cache, they will also be loaded. If pages go unused, they may also be |
26 |
swapped out as needed. [I'm a little fuzzy here as to weather a read-only |
27 |
page is ever written to actual swap space, the kernel may just remember |
28 |
where (on disk) the original is keep and release the real memory page.] |
29 |
If the library was opened with dlopen() an appropriate call to dlclose() |
30 |
will cause the library to be munmap()ed, but the library may still remain |
31 |
in cache. As with all mmap()ings, when the process dies the memory is |
32 |
(effectively) munmap()ed. In either munmap() case, the read-only pages of |
33 |
the library may stay in active memory or swap memory if opened by another |
34 |
process, and may stay in cache even if no other process is currently using |
35 |
the them. The copy-on-write pages will be freed (from either active or |
36 |
swap) when munmap()ed. |
37 |
|
38 |
At least, that's the gist of it. There's a lot there that I've glossed |
39 |
over, but it should make memory management of shared libraries make a |
40 |
little sense. |
41 |
|
42 |
-- |
43 |
"If there's one thing we've established over the years, |
44 |
it's that the vast majority of our users don't have the slightest |
45 |
clue what's best for them in terms of package stability." |
46 |
-- Gentoo Developer Ciaran McCreesh |