On Thu, Aug 20, 2020 at 04:51:57PM -0700, Colin Cross wrote:
> >
> > Yes, been in this part of code too long ago, managed to forget. You know
> > I'm wondering do we really need a human readable names here? Maybe it would
> > be more convenient to keep say u64 number instead? This would eliminate
> > need to access VM at all. From user space point of view there should be
> > no difference how to recognize such VMAs (by name or by some ID). Or there
> > some need for string solely?
>
> Numbers instead of strings would require some central registry to
> decode them, which would make it much harder to use. You can see some
This is not anyhow different from number constants. You simply need a
central registry of strings.
enum anon_codes {
atexit_handlers = 1,
linker_alloc = 2,
...
};
ed432000-ed433000 r--p 00000000 00:00 0 [anon:1]
ed442000-ed4a6000 r--p 00000000 00:00 0 [anon:2]
...
the thing is that the string constants have no meaning outside of the
user space application which use it. Moreover a user (while would read
it via procfs) must have no assumption about their name meaning at all.
> examples of how Android uses it at https://pastebin.com/BQZ1vZnJ for
> the cat proces and https://pastebin.com/YNUTvZyz for an ART process.
> We label individual stacks with their TIDs (useful since the stack TID
> annotation was reverted in 65376df582174ffcec9e6471bf5b0dd79ba05e4a),
> the various heaps created by different allocators, and much more. The
> data is consumed manually for debugging, as well as by various memory
> stats collection and analysis tools.
Aha, thanks! I see the labeling. So baically the benefit of string
constants is the following:
- they are human readable
- they are 255 bytes long (for now)
While downsides are:
- a way more longer procfs output
I don't have some strong opinion here. Still thanks a huge for examples.
