[00:41:32] Krinkle: I'd be happy to read the draft, if you like [00:58:23] sampling profilers like perf work by periodically interrupting program execution to record what the program was doing at the moment it was interrupted. How they determine what the program was doing depends a lot on the machine architecture and the operating system's calling convention [01:03:00] on linux + x86, when a perf interrupt occurs, linux copies the current value of all CPU registers and lets perf look at those [01:06:20] on x86 in 64-bit mode, the %rip register is used as the instruction pointer. Its value is the memory location of the next instruction the processor will execute [01:12:08] to map that memory location to a symbol name, perf looks at the process's currently mapped memory regions. if the instruction pointer points to an address in a region of memory that was loaded from a file, perf can figure out the location in the file that corresponds to the instruction pointer's value [01:14:52] with any luck there is a debug table in the file that says where each function starts and ends [01:29:03] to get the call stack, perf can look at another register, %rbp, which contains the frame pointer. its value is the memory address of the region of memory of the current stack frame. because each stack frame also contains a pointer to its parent stack frame, if you know where the current stack frame starts, you can walk the entire stack and figure out the call chain that brought you to where [01:29:05] you are in the program [01:33:05] in the case of java, the memory location indicated by the instruction pointer won't be object code loaded from some file, but instead code that is generated dynamically at runtime [01:34:12] perf-$pid.map is basically a fallback mechanism for perf to try and map the memory address to a symbol [01:34:35] how perf-$pid.map is populated is up to the VM [01:39:27] when you are running code written in a dynamically interpreted languages the instruction pointer will point to a memory location in the interpreter's eval() function [01:40:19] e.g. if you profile a python program the time spent executing python code will show up as time in PyEval_EvalFrameEx [01:43:02] if perf knew more about the python VM it could inspect the data structures that the python interpreter uses to represent the stack frame of dynamically evaluated code, and use that to determine what the program is doing. that's basically what excimer does with php [01:44:35] unfortunately the way each language runtime represents current program state internally varies, there's nothing like a standard that perf could use [01:47:13] um, I'm rambling. to answer your question (I think): if perf can't map a memory address to a symbol name, when you run perf report you'll just see the address with no symbol name associated with it [01:52:49] e.g. i just ran 'sudo perf record -- ls ; perf report' and got this: https://imgur.com/a/AO3yuL4 . i don't have debug symbols for the current kernel, so kernel functions (entries with [kernel.kallsyms]) don't have symbols [01:53:15] ^ Krinkle ping in case you missed any of this :) gotta go now [14:53:39] ori: thx, I guess I wasn't sure whether the jit-ed code from the vm would actually make its way onto the "real" stack. So in a way apart from needing symbol translating, with jit you do "see" your actual program through perf events. [14:54:01] I'll send you a link tomorrow for review, that'd be awesome :)