Memory reporter for structured clone buffers

NEW
Unassigned

Status

()

Core
JavaScript Engine
5 years ago
4 years ago

People

(Reporter: sfink, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [MemShrink:P2])

I swear I typed out this bug description once before, but I don't see it...

Before bug 868700, it was fairly easy to leak structured clone buffers. In the Broadway.js h264 decoder demo, this would give me >90% unclassified-heap bytes. Worse, those bytes would be stored in char*/size_t field pairs, not any sort of structured type.

Bug 868700 keeps the data always in a JSAutoStructuredCloneBuffer, which makes the memory easier to find and also fixes the leak. But it's still be possible to construct structured clones and never deserialize them. Also, if you have postMessages going at a high rate between the main thread and worker threads, you can accumulate quite a few clone buffers. I don't know if it's worth creating a memory reporter for these hypothetical cases.
Whiteboard: [MemShrink]
Whiteboard: [MemShrink] → [MemShrink:P2]
Where do these buffers end up being held?
(Assignee)

Updated

4 years ago
Assignee: general → nobody
You need to log in before you can comment on or make changes to this bug.