Open
Bug 1145297
Opened 9 years ago
Updated 2 years ago
Hang on http://www.dell.com/us/business/p/precision-t1700-workstation/pd with js profiling turned
Categories
(Core :: Gecko Profiler, defect, P3)
Tracking
()
NEW
People
(Reporter: jrmuizel, Unassigned)
References
(Depends on 3 open bugs, Blocks 2 open bugs)
Details
No description provided.
Comment 1•9 years ago
|
||
Jeff showed this to me here in the office. I'm pretty sure this is caused by a combination of two things: 1. The sampler calls PCToLineNumber which is taking a HUGE amount of time in the perf-profiles of this hang. I suspect it's hitting a particularly degenerate case where there are a lot of sourcenotes for this function. 2. mstange recently modified the profiler sampling implementation, so that it tries to approximate a sample every 1ms, instead of blindly sleeping 1ms between samples. I.e. the sampler now takes into account the amount of time spent sampling, and tries to subtract that from the amount of time to wait until the next sample. The combination of these two factors is most likely leading to a situation where the amount of time taken sampling is so large that the mainThread doesn't get to execute for very long (or at all) before being interrupted again for the next sample. Markus is testing this hypothesis now by reverting the sampling timer to the old method of blindly waiting 1ms between samples.
Updated•7 years ago
|
(In reply to Kannan Vijayan [:djvj] from comment #1)
- the profiler sampling implementation tries to approximate a sample every 1ms, instead of blindly sleeping 1ms between samples.
This was changed in bug 1685937, to avoid too-short sleeps when the sampler is working for a significant proportion of the interval time.
I'll keep this bug open, since dependent bug 929950 and bug 1409953 (about PCToLineNumber
) are still open.
You need to log in
before you can comment on or make changes to this bug.
Description
•