Closed Bug 1576551 Opened 5 years ago Closed 5 years ago

Use BlocksRingBuffer in ProfileBuffer

Categories

(Core :: Gecko Profiler, task, P2)

task

Tracking

()

RESOLVED FIXED
mozilla71
Tracking Status
firefox71 --- fixed

People

(Reporter: mozbugz, Assigned: mozbugz)

References

Details

Attachments

(4 files, 1 obsolete file)

Instead of implementing its own circular buffer, ProfileBuffer will now use BlocksRingBuffer.

That BlocksRingBuffer will be stored in CorePS (in platform.cpp) because it will need to live even when the profiler is not enabled (because some slightly-racy function like profiler_add_marker may still try to store some data shortly after the profiler has been disabled).

Because BlocksRingBuffer is stored outside of ProfileBuffer, ProfilerBacktrace will need to also store the BlocksRingBuffer that its ProfileBuffer uses.

This just replaces ProfileBuffer's self-managed circular buffer with a
BlocksRingBuffer.

Depends on D43420

BlocksRingBuffers will be stored outside of ProfileBuffers, as we need to be
able to safely access the underlying buffers when profilers are not enabled.

Depends on D43421

Because any thread could be holding the BlocksRingBuffer lock (e.g., when it
will store markers), we need to ensure that the sampler thread takes that lock
before stopping a thread, because the sampler then needs to lock the buffer when
storing its data.

Depends on D43422

Attachment #9088104 - Attachment description: Bug 1576551 - CorePS contains the main BlocksRingBuffer, ActivePS's ProfileBuffer uses it - r?gregtatum → Bug 1576551 - Store BlocksRingBuffer outside of ProfileBuffer - r?gregtatum

Add some stats (off by default) around streaming JSON, as the following patches
may affect it.

Now that we are using a byte-oriented BlocksRingBuffer instead of an array of
9-byte ProfileBufferEntry's, internally the profiler sets the buffer size in
bytes. However all external users (popup, tests, etc.) still assume that the
requested capacity is in entries!

To limit the amount of changes, we will keep assuming externally-visible
capacities are in entries, and convert them to bytes.
Even though entries used to be 9 bytes each, and BlocksRingBuffer adds 1 byte
for the entry size, some entries actually need less space (e.g., 32-bit numbers
now take 6 bytes instead of 9), so converting to less than 9 bytes per entry is
acceptable.
We are settling on 8 bytes per entry: It's close to 9, and it's a power of two;
since the effective number of entries was a power of two, and BlocksRingBuffer
also uses a power of two size in bytes, this convertion keeps sizes in powers of
two.

Depends on D43421

Attachment #9088105 - Attachment is obsolete: true
Pushed by gsquelart@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/ec72dfc7301e
AUTO_PROFILER_STATS(locked_profiler_stream_json_for_this_process) - r=gregtatum
https://hg.mozilla.org/integration/autoland/rev/d7ee4148aad9
Use BlocksRingBuffer in ProfileBuffer - r=gregtatum
https://hg.mozilla.org/integration/autoland/rev/366030bd2d84
Assume capacity is in 8-byte entries - r=gregtatum
https://hg.mozilla.org/integration/autoland/rev/b6d73f5042a7
Store BlocksRingBuffer outside of ProfileBuffer - r=gregtatum
Pushed by gsquelart@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/af093f06fb74
AUTO_PROFILER_STATS(locked_profiler_stream_json_for_this_process) - r=gregtatum
https://hg.mozilla.org/integration/autoland/rev/524f84e0fc78
Use BlocksRingBuffer in ProfileBuffer - r=gregtatum
https://hg.mozilla.org/integration/autoland/rev/3dfc76ea7bd9
Assume capacity is in 8-byte entries - r=gregtatum
https://hg.mozilla.org/integration/autoland/rev/fd3a29881783
Store BlocksRingBuffer outside of ProfileBuffer - r=gregtatum
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: