Re: Why is virtual memory so high? (crash)
Re: Why is virtual memory so high? (crash)
- Subject: Re: Why is virtual memory so high? (crash)
- From: Eric Gouriou <email@hidden>
- Date: Wed, 21 Jan 2009 22:51:59 -0800
On Jan 21, 2009, at 9:45 PM, Justin C. Walker wrote:
On Jan 21, 2009, at 02:57 , Mario Emmenlauer wrote:
Justin C. Walker wrote:
On Jan 20, 2009, at 08:43 , Mario Emmenlauer wrote:
Shawn Erickson wrote:
On Mon, Jan 19, 2009 at 1:18 AM, Mario Emmenlauer <email@hidden
> wrote:
I have a large C/C++ project with thousands of lines of code and
many thirdparty-libraries. When it startes up, it reserves
around 1.8GB
of virtual memory (40MB real memory), and I don't know why.
Are there better/other tools I could try to inspect where the
additional vmem is reserved?
vmmap
Thanks! I used vmmap, it claims ~600MB should be used by my
process. Activity Monitor instead shows 1220MB virtual memory
usage, twice as much. Who is right? Am I doing something wrong?
The two could be using different algorithms to account for pages.
Might be worth filing a bug report with examples.
Seems I'm stuck again. The 1.2GB that Activity Monitor shows are
correct, since my application crashes after reserving 2.7GB real mem.
vmmap instead (incorrectly?) claims only 600MB whould be used (which
is still a lot for an idle GUI app with only 60MB real memory).
I must be missing something!
Try this: In Activity Monitor, select View->Columns->Shared Memory,
and see what happens.
Since I don't have the code for either vmmap or Activity Monitor
(and since I would not want to spend any time wading into the Mach
VM tar baby), I can't tell for sure what's going on, but I think the
answer for you is that the two programs are telling you different
things.
Just a guess but vmmap may not be showing all or parts of the shared
memory
region containing the dyld shared cache which is mapped in every process
of a given architecture.
Activity Monitor, top and vmmap all have slightly different
heuristics for what they
report.
By the way, what is IOKit with 281MB and STACK GUARD with 56MB?
Both seem unreasonably high...
Stack guard chunks are 1 page, so I suspect that vmmap is just
lumping claimed but unallocted VM to that category (possibly a
[more or less harmless] bug). For IOKit, I can't say for sure.
Are you mapping lots of memory? I notice that Safari has a 250MB
chunk allocated to IOKit, while python has nothing of that type.
firefox (freshly started) uses 1.2GB virtual mem (vs 80MB real mem),
and other programs (smartcvs, ...) have these unrealistic high
numbers
too. Can I explicitly "un-map" or "close" IOKit, STACK GUARD, __TEXT
and others?
I doubt it. That would amount to pulling the rug out from under the
app. I don't think the STACK GUARD pages count for much (as I
indicated above). As for IOKit, I suspect it's critical to the
app's operation.
The IOKit region is typically related to some video card memory
region.
All processes displaying UI will have that mapping.
If anything those "unrealistic" numbers are realistic and other
sources (e.g., top)
are underreporting some regions.
Caveat: those are just "from the top of my head" recollection of
issues I never paid
too much attention to. When VSIZE constrained, LP64 is your friend. In
most
other cases VSIZE doesn't matter and RPRVT is the interesting column...
Eric
__TEXT is, I assume, code.
As I said, I'm not wading into the Mach VM code to grok what's going
on there, but someone else may be able to shed some light.
What problem are you trying to tackle here? You may be chasing
chimaeras...
Justin
--
Justin C. Walker, Curmudgeon-At-Large
Institute for the Absorption of Federal Funds
--------
Men are from Earth.
Women are from Earth.
Deal with it.
--------
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden