Open Bug 1145297 Opened 9 years ago Updated 2 years ago

Categories

(Core :: Gecko Profiler, defect, P3)

x86
macOS
defect

Tracking

()

People

(Reporter: jrmuizel, Unassigned)

References

(Depends on 3 open bugs, Blocks 2 open bugs)

Details

      No description provided.
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.
Blocks: 1329181
Blocks: 761253
Depends on: 848071
Depends on: 929950
Depends on: 1409953

(In reply to Kannan Vijayan [:djvj] from comment #1)

  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.

Severity: normal → S3
Depends on: 1685937
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.