Closed Bug 1379933 Opened 2 years ago Closed 2 years ago

Streamline ProfileBuffer's grammar

Categories

(Core :: Gecko Profiler, enhancement)

enhancement
Not set

Tracking

()

RESOLVED FIXED
mozilla56
Tracking Status
firefox56 --- fixed

People

(Reporter: njn, Assigned: njn)

References

Details

Attachments

(5 files, 3 obsolete files)

Bug 1379565 identified the grammar formed by the ProfileBuffer's entries. This bug will streamline the grammar a bit.
They serve no useful purpose.
Attachment #8885200 - Flags: review?(mstange)
Assignee: nobody → n.nethercote
Status: NEW → ASSIGNED
When a sample with a label and a dynamic string is written to the
ProfileBuffer, the profiler currently joins them together (up to a max length
of 512, omitting any that exceed this) and then writes a CodeLocation entry
with an empty string followed by a sequence of EmbeddedString entries. When
parsing those entries, we allow a length up to 8192, but that limit is never
reached due to the prior limit of 512.

This patch makes the following changes.

- Removes the joining at write time. Labels and dynamic strings are now written
  separately into the ProfileBuffer, without any length limitations. (Labels
  also always take up one entry, because they only require a single pointer,
  because they are always static strings.) The joining is instead done when the
  ProfileBuffer is parsed, and the max length is 1024; any strings exceeding
  this length are truncated, rather than omitted. (This also happens to be
  outside the profier's critical section.)

- Renames CodeLocation as Label and EmbeddedString as DynamicStringFragment.
  This makes the ProfileBuffer entry names better match the names used in
  GeckoProfiler.h.

- Moves AddDynamicCodeLocation(), now called addDynamicStringEntry(), into
  ProfileBuffer.

- Adds some testing of overly-long dynamic strings to the GTest.
Attachment #8885202 - Flags: review?(mstange)
Also, hasKind() can be removed.
Attachment #8885204 - Flags: review?(mstange)
Attachment #8885200 - Flags: review?(mstange) → review+
Blocks: 1367406
Attachment #8885204 - Attachment is obsolete: true
Attachment #8885204 - Flags: review?(mstange)
Attachment #8885207 - Attachment is obsolete: true
Attachment #8885207 - Flags: review?(mstange)
This patch changes ProfileBuffer arguments from pointers to references. For
functions that modify the ProfileBuffer, it also moves the argument to the end.
Attachment #8885656 - Flags: review?(mstange)
(In reply to Nicholas Nethercote [:njn] from comment #2)
> Labels and dynamic strings are now written
>   separately into the ProfileBuffer, without any length limitations. (Labels
>   also always take up one entry, because they only require a single pointer,
>   because they are always static strings.)

I'm worried about this change, specifically about the lack of length limitations for dynamic strings. If I run JavaScript where the script is not in a discrete file, but instead in a data URL, won't we copy that long URL into the buffer during sampling? I think there needs to be a cap here.
Or when we're painting a document that's a very long data URL, will we copy the long dynamic string of the nsLayoutUtils::PaintFrame pseudo stack frame into the buffer in its entirety on every sample?
(In reply to Markus Stange [:mstange] from comment #8)
> If I run JavaScript where the script is not
> in a discrete file, but instead in a data URL, won't we copy that long URL
> into the buffer during sampling?

This was the hypothesized problem in bug 1217542, but unfortunately the page in that bug no longer reproduces the bug for me and Jeff's saved testcase is gone.
Comment on attachment 8885202 [details] [diff] [review]
(part 2) - Improve ProfileBuffer's handling of labels and dynamic strings

Review of attachment 8885202 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good except for the lack of a cap on the length on dynamic strings when they're copied into the buffer.
Attachment #8885202 - Flags: review?(mstange) → review+
Attachment #8885462 - Flags: review?(mstange) → review+
Attachment #8885464 - Flags: review?(mstange) → review+
Attachment #8885656 - Flags: review?(mstange) → review+
Updated version:

- Reduces kMaxFrameKeyLength from 1024 to 512, to match the old limit.

- If a dynamic string is present when privacy is enabled, it's now replaced
  with "(private)".

- If a dynamic string is present and longer than kMaxFrameKeyLength, it's now
  replaced with "(too long)".
  
- The GTest is updated accordingly.
Attachment #8885202 - Attachment is obsolete: true
https://hg.mozilla.org/integration/mozilla-inbound/rev/d4d99d47b9fa2166105b03cb7cb86c18930f6e6b
Bug 1379933 (part 1) - Remove Sample entries from the ProfileBuffer. r=mstange.

https://hg.mozilla.org/integration/mozilla-inbound/rev/00674f36f7904356b5bf2aba2779fe0cfad445cc
Bug 1379933 (part 2) - Improve ProfileBuffer's handling of labels and dynamic strings. r=mstange.

https://hg.mozilla.org/integration/mozilla-inbound/rev/158b7d6d7ea6c5f4e5e6093eb2be51da1bf590ab
Bug 1379933 (part 3) - Start all ProfilerBufferEntry methods with an upper case letter. r=mstange.

https://hg.mozilla.org/integration/mozilla-inbound/rev/f7e6d96eb514e1f50933cc5ff8064afb0e5830da
Bug 1379933 (part 4) - Start all ProfilerBuffer methods with an upper case letter. r=mstange.

https://hg.mozilla.org/integration/mozilla-inbound/rev/3fe4adc63baf237235f439667af42cc5f9d460f9
Bug 1379933 (part 5) - Tweak ProfileBuffer arguments. r=mstange.
Comment on attachment 8885968 [details] [diff] [review]
(part 2) - Improve ProfileBuffer's handling of labels and dynamic strings

Review of attachment 8885968 [details] [diff] [review]:
-----------------------------------------------------------------

Carrying over mstange's r+ from the prior version.
Attachment #8885968 - Flags: review+
You need to log in before you can comment on or make changes to this bug.