Consider caching LUL unwind information
Categories
(Core :: Gecko Profiler, task, P2)
Tracking
()
People
(Reporter: mstange, Unassigned)
References
(Blocks 1 open bug)
Details
When LUL initializes, it converts Dwarf unwind information to its internal representation. This conversion happens for every library on every process startup. It's really slow for libxul.so, our largest library.
My understanding is that the LUL unwinding representation is always the same. Would it be possible to cache this representation, maybe to the file system? We could key it by the library's build ID.
If we map the same cache file into each process, this would also save memory.
|
Reporter | |
Comment 1•4 years ago
|
||
Sandboxing might make the "file system" part of this proposal hard. (Or it might not, I don't know enough about sandboxing to say.)
And I don't think we can use IPC to transfer file handles or shmems to the content processes, because we'll usually want to start profiling before the IPC system is initialized.
(In reply to Markus Stange [:mstange] from comment #1)
Sandboxing might make the "file system" part of this proposal hard. (Or it might not, I don't know enough about sandboxing to say.)
I don't know enough either, which I confirmed while trying to prove that the Base Profiler starts before the sandbox -- it seems some processes are sandboxed from the outside!... But I found this interesting comment in the main() function:
// We need to initialize the sandbox TargetServices before InitXPCOMGlue
// because we might need the sandbox broker to give access to some files.
So there should be ways to allow a Profiler cache file to exist. TBC.
And I don't think we can use IPC to transfer file handles or shmems to the content processes, because we'll usually want to start profiling before the IPC system is initialized.
We can pass some information during process launch, like we already do through env-vars like MOZ_PROFILER_STARTUP, and I think there are other ways (command line args, prefs, others?)
Description
•