Use a better pointer for the Android UI thread's stack top when registering with the profiler
Categories
(GeckoView :: General, defect)
Tracking
(firefox91 fixed)
| Tracking | Status | |
|---|---|---|
| firefox91 | --- | fixed |
People
(Reporter: bugzilla, Assigned: bugzilla)
References
(Blocks 1 open bug)
Details
(Whiteboard: [geckoview:m91])
Attachments
(1 file)
We currently register the Android UI thread with the profiler using the PROFILER_REGISTER_THREAD macro.
This macro uses the address of a local variable as an estimate for the top of the thread's call stack. The profiler's sampling thread does not walk the stack any further above this value.
This works fine most of the time, as it's usually one of the first things that we do when running a new thread.
On the other hand, the Android UI thread already has a bunch of stuff on the stack by the time we go to set this, plus we have two or three calls already on the stack as well. Using our current stack frame as an estimate for the top of the stack results in the profiler omitting numerous frames from the Android UI thread because it mistakenly believes that it needs to stop walking the stack sooner than it actually needs to!
Instead of using the macro, I'd like us to use pthreads to resolve the real stack top and supply that pointer to the profiler instead.
|
Assignee | |
Comment 1•5 years ago
|
||
We were previously registering the Android UI thread with the profiler using
the PROFILER_REGISTER_THREAD macro.
This macro uses the address of a local variable as an estimate for the top of
the thread's call stack. The profiler's sampling thread does not walk the stack
any further past this value.
This works fine most of the time, as it's usually one of the first things that
we do when running a new thread.
On the other hand, the Android UI thread already has a bunch of stuff on the
stack (including VM frames) by the time we go to set this, plus we have two or
three of our own calls already on the stack as well. Using the current stack
frame as an estimate for the top of the stack results in the profiler omitting
numerous frames from the Android UI thread because it mistakenly believes that
it needs to stop walking the stack sooner than it actually needs to!
Instead of using the macro, this patch uses pthreads to resolve the real stack
top and supplies that pointer to the profiler instead.
|
||
Comment 3•5 years ago
|
||
| bugherder | ||
Description
•