[simpleperf] Why do we need to read jit/dex descriptors 3 times?

[RajatChauhan-0575]

As per the code we are reading the jit/dex descriptors 3 times as below:

1. From the periodic event of 100ms
   We just simply read all process and store the jit/dex debug info into the perf.jit_cache_data file and the record as PERF_RECORD_MMAP2 in perf.data (not sure why we need this?)
2. Whenever we read a perf event mmap buffer and get a sample, we read the jit/Dex info using ReadProcess() of the pid and store the data in perf.jit_cache data, so that we have the most recent jit/Dex data and we store the sample into perf.data as PERF_SAMPLE_RECORD (this is also understood as we need to have latest jit/debug info as soon as we receive sample)
3. When doing unwinding of the record, if the call stack is broken we read the jit descriptor and use that data(this is somewhat understood)

Why do we need to have point 1, because anyways we are not processing the mmap2 samples in report and we have the point 2 to get the latest data corresponding to each sample?

There are 2 questions

1. Why we need point 1 above?
2. Why we ommit mmap2 record during report?

[enh-google]

@yabinc

[yabinc]

Thanks for the question!
The understandings of for item 1 and 3 are correct.
But for item 2, when we read a sample record, we check if we have monitored this process before, by checking pids_with_art_lib_[r.tid_data.pid]. If not, we call MonitorProcess() to monitor this process, and call ReadProcess() to get the latest JIT/Dex entries once for the current sample. The next time we see a sample from the same process, pids_with_art_lib_[r.tid_data.pid]=true, so we won't call MonitorProcess() and ReadProcess() again. The code is https://cs.android.com/android/platform/superproject/main/+/main:system/extras/simpleperf/JITDebugReader.cpp;l=259;bpv=1;bpt=1.

So simpleperf isn't reading the latest JIT/Dex entries for every sample. Instead, it uses item 1 (read JIT/Dex entries periodically) and item 3 (read immediately when having unwinding error). It's mostly a trade-off between process time and accuracy. But since there is a delay between generating a sample and unwinding it, and JIT/Dex entries can change in between, reading the latest JIT/Dex entries when processing a sample doesn't necessarily get a correct unwinding result.

The item 2 (monitor a process when seeing the first sample of it), is mostly for processes added during recording (like
for system wide recording, and when a monitored process creates child processes).

For mmap2 record, it's used when reporting, as in https://cs.android.com/android/platform/superproject/main/+/main:system/extras/simpleperf/thread_tree.cpp;l=397;drc=7369db2599643b98b60b3b6237178919f9b7726d

[RajatChauhan-0575]

Thanks for you detailed reply!!
One more thing, why we did not choose the Java agent method here instead of reading jit/Dex descriptors, like how perf use jvmtiagent to get he hottest symbols data for java app? Are there any other designs/ways thought of before finalising this method?

[yabinc]

Honestly java agent method is never considered/needed before. Because:

1. Android JVM has a builtin profiler to get java callstacks from a long time ago. So simpleperf focuses on native code.
2. Android changed to ART (which compiles java code into native code) before simpleperf was created. So if we really want to profile java code using simpleperf, we can fully compile the application. Then ART changed to use more JIT methods. It was natural to add GDB JIT debug interface to debug and profile native code in JIT methods, as in https://sourceware.org/gdb/current/onlinedocs/gdb.html/Declarations.html.
   ART exports even more data than the standard interface. So simpleperf can unwind and symbolize interpreted java code.

From https://source.android.com/docs/core/runtime/art-ti, ART also supports JVMTI agent. Comparing it to the JIT debug interface, I feel:

1. JVMTI is more powerful at inspecting or changing JVM status. But this also means it can be used in less places for security reason.
2. JVMTI needs to load agent library in the application. Probably more complex to implement and use.
3. JVMTI can get java callstack. Probably it gets the callstack similar to the JVM builtin profiler, by stopping a thread and read it's java callstack stored in the JVM. Two main drawbacks are: a) we can't get native callstack if the app uses JNI methods. b) we can't use perf events to control when to generate samples.

[RajatChauhan-0575]

Sure got it,
Also is there any way I can show the source line in Java file and samples corresponding to each source line, considering I have the elf data of the jit/Dex code and the load addr?
Annotate.py is not working the way it should be, it's showing me the path to Dex/oat files and not the actual Java file and source line

[yabinc]

Good question! Although in theory it is possible, source line annotation for Java code isn't supported yet. If you'd like to help file a ndk issue, it can give more motivation to get it done.

[RajatChauhan-0575]

Sure, I will file an issue
Thanks again for all your responses!