Request for Guidance on Memory-Infra Usage on Android

[Ke Yu]

Hello Team,

I‘m from the Edge Mobile team and have some questions about Memory-Infra.

From the documentation, Memory-Infra is not only used for memory_benchmarks (System Health), but also for root cause analysis when reproducible memory regression happens. It seems to be mainly for lab-level or local use, without production scenarios.

I ran into some issues while using memory-infra:

1. After enabling the relevant #memlog flags, the pointers in chrome://memory-internals remain unresolved, so I cannot see the detailed stacks. However, in the examples from heap_profiler.md - Chromium Code Search, the stacks are visible. How can I address this problem?
   The trace expected to be captured by Memory-Infra:
   
   The trace that I captured:
   

    

5. 2. In chrome://memory-internals, clicking 'Save Dump' only shows "Save successfully". From the code, the file is     stored under the user directory. I was able to get this file by modifying the code, but I do not understand the intention of saving the dump in the user directory.

Memory-Infra’s memory categorization is quite detailed,  but do we have any way to see code-level or reference-level details for memory allocations in both Android Java and native code?

Thanks for your guidance.

Regards,

Ke

[Egor Pasko]

Hi Ke,

The documentation references 'pseudo stack', which consists only of trace events. Perhaps, if you enable more tracing categories, you will see more detailed 'stack' information?

[Ke Yu]

Hello Egor,

Thank you very much for your reply.

I noticed that while I am able to capture M events containing stack frames from our Android app on an arm64 Android 14 device, I cannot do the same on an x86 Android 10 emulator via chrome://tracing, which might be related to differences in the Android version or the CPU architecture.

I am now able to parse the captured trace files using symbolize_trace, but I found that the data does not contain much information directly related to our app’s code logic.

Following your suggestion, I enabled additional trace categories, but after parsing the trace files, I still did not see many app-relevant details. Most of the Stack Frames(ƒ) events point to lower-level system calls or framework stacks.

Could you advise if there is a way to obtain more business-logic-related memory information? Would this require us to add custom trace_event definitions ourselves?

Additionally, I observed a discrepancy between two closely timed M events:

The first M event contains malloc data along with ƒ and Object Type (Ⓣ ) information, with a total across all processes of 62.9 MB.

The second M event, although it contains more categories, does not include detailed ƒ/Ⓣ events, but its malloc total is 328 MB.

I’m not quite sure what causes this difference. Could you provide some insight into this behavior?

Thank you for your guidance.

Regards,

Ke

---

From: Egor Pasko <pa...@chromium.org>
Sent: Monday, October 13, 2025 9:21 PM
To: Ke Yu <k...@microsoft.com>
Cc: Siddhartha S <ss...@google.com>; li...@chromium.org <li...@chromium.org>; memor...@chromium.org <memor...@chromium.org>; Yu Jiang <yuj...@microsoft.com>; Haibo Yu <yuh...@microsoft.com>; Wenbin Liu <liuw...@microsoft.com>
Subject: [EXTERNAL] Re: Request for Guidance on Memory-Infra Usage on Android