We currently restrict native stacks to 25 frames maximum[1]. The problem however is that only ~11% of native stacks seem to fall under this mark, and while it is often possible when manually inspecting stacks to infer what the non-truncated stack might look like, it can make it difficult to analyze programmatically or create visualizations, as strategies for grouping stacks together fall apart. One such example is that I am currently trying to visualize hang data like a profiler would, using a tree structure. Truncating to 25 frames causes there to be far too many roots of this tree, since the root becomes whatever the 25th frame up is. mconley suggested that the reason for this was (likely) due to telemetry ping size. If this is accurate, can we trade a lower value of kMaximumNativeHangStacks[2] for a higher value of sMaxNativeFrames? I ran some processing over the pings that we do have trying to stitch stacks together by guessing what their parents are, and the longest stack that didn't break my tool due to recursion was 74 frames long[3]. I think if we cut kMaximumNativeHangStacks down to 100 from 300 and brought sMaxNativeFrames from 25 to 75, our worst-case ping size would go down, and we would have more useful information for analysis at a large scale. 1: http://searchfox.org/mozilla-central/rev/7057a51c5cf29b5b115b1db19ace2cfe3fd83a0e/toolkit/components/telemetry/ThreadHangStats.h#61 2: http://searchfox.org/mozilla-central/rev/7057a51c5cf29b5b115b1db19ace2cfe3fd83a0e/xpcom/threads/BackgroundHangMonitor.cpp#43 3: And the distribution looked like this: https://d2ppvlu71ri8gs.cloudfront.net/items/2b3s3G3T3C2a2P1I2z0y/distribution.png

This should be resolved with Bug 1365749.