pmap
 

Given the following output, can someone tell me:
1) Hex Decimal
080b0fff = 134942719
08048000 = 134512640
Diff = 430079

Why does pmap indicate the size as 420k?

2) What's the purpose of the Offset column when the whole address range is shown?

3) The "rwxpc" column indicates that this segment is readable, executable, private, and the + sign indicates that COW is required.

If there has been 3 forks (ie 1 parent and 3 child processes), and only of these three child processes has attempted to write to the segment, is this enough to cause this + sign to change to a - sign? Or all 3 child processes needs to have attempted to write to the segment, and all 3 has a COW, before the - sign will appear?

4) What does the I/W/A column indicate?

420k is really 420KiB, meaning 420 x 1024 bytes (ie 430080 bytes). We've been happily misusing SI prefixes for some time now :)

It's just the offset into the paging object.

If the region is shared by multiple processes, then the copied flag would have to remain 'uncopied' while there was more than one process still capable of writing to it (ie, the shared region cannot change to '-' until each process has its own copy).

The 'I' is the inheritance type of the region (ie, whether child processes share, copy or do not have the region); the 'W' is the wired count of the region (ie, whether the region is wired in and cannot be paged, as is typical of kernel memory); the 'A' is the advice parameter (ie, hints regarding the page priority of the region).

neonsignal, thanks for the explanations. Regarding the following, can you give me some examples of what is a "wired count"? I'm not following what you meant by "whether the region is wired in". As for the number "1" under the "I" column, I guess this is because the memory is shown as a COW type with the "+" sign under the "rwxpc" column?
BTW, I've noticed differences between the pmap and jmap output. Can you tell me how I should account for the differences?

These are pages that cannot be swapped out, typically memory that is being used by the kernel - stacks, memory pools, page tables, and the like).

No, it means that this page is of type VM_INHERIT_COPY, meaning that child processes will get a copy of the page (which is the default). The COW is showing how any copies are to be handled (functionally).

I haven't used jmap, I'll leave that question for someone else! You might want to give an example.

Thanks. Would I be correct if I say, however, that if there is no COW, as indicated with the "+" sign, then there won't be a "1" under the "I" column also? Basically the way I get what you are saying is that the "1" under the "I" column means the child will get a copy, and the "+" means the child will get the copy when it attempts to write to that area. Right?

Yes. I was just being pedantic in pointing out that in theory the child could still get a copy even if the system didn't have a copy-on-write mechanism (instead just a straightforward copy). And you could have a copy-on-write page that is memory shared between unrelated processes, even if it wasn't a page that was inheritable by child processes. In other words, that the two concepts are independent. But in practice, yes, a page that is going to be inherited by the child will be copied when the child (or parent) writes to it.

For the jmap vs pmap output example, here's what I see (truncated a lot of other stuff).
Essentially the key points I notice are:
1) jmap lists the code section and pmap lists both code and data sections.
2) Size in jmap is different than size in pmap.
For example:
46k vs 40k for java
1225k vs 104k for ld-2.4.so
1261k vs 104k for liba.so
47343k vs 31652k for liba.so
3) pmap lists things like [heap], [anon]. What are these?

Can I ask, based on looking at pmap, how can I tell what is the stack and heap boundary addresses?

jmap
pmap

It looks more like jmap is including code and the other segments into a single total. If you add the pmap segments, you get roughly the same totals.

For example,
and so on

These are just different segments used by the executable. The code segment is obvious (because it is not writable). But there can also be initialized data segments, uninitialized data segments, dynamically allocated data space (heap), and stack space, etc (the exact set of segments used can vary).

Once the heap and stack segments are located, can't you just add the size to the start address to get the end address? Is that what you mean?

Thanks. Didn't realize that jmap is adding the code and data segment. As for I suppose so. However, I'm not sure if the stack or heap may be broken up in a non-contiguous memory space. If so, I guess the lowest address for the stack(s) is the top of the stack, and the highest address for the heap(s) is the top of the heap. However, what would the heap be indicated as? Is it [anon]? Anyway to see look at what's on the stack?

The mapping is only a virtual address space, not a real one. The stack is necessarily contiguous in this virtual address space (in theory, one could implement a non-contiguous stack, but on current systems it would be seen as an unnecessary complication). The heap doesn't have to be contiguous, but typically implementations are (which is why it is allocated at the end of all the low address segments, so that it can dynamically grow).

The pmap can't be relied upon to identify segment types (the contents will vary depending on how the language/code works). Often the heap will be the largest writable segment at the end of the low address segments, and the stack will be the last of the high address segments.

Yes, the stack is growing from the end address towards the base address.

Yes, although a heap can be grown at run time, so that isn't a hard limit.

Depends on how smart the pmap implementation is. Your example above had the heap identified, but on some systems it may be just another 'anon' segment.

To view the contents of these address spaces, it would be usual to employ a debugger (eg use gdb to dump memory contents). In a Java context, it might be more useful to run a Java debugger, though that might not have quite the same low level functionality?