1577825 - SharedArrayBuffer memory is not accounted for

Status: RESOLVED FIXED

(Core :: JavaScript: GC, defect, P1)

Description

[Jon Coppeard (:jonco)]

The mapped memory used for shared array buffers is not currently reported to the GC memory accounting framework.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The priority flag is not set for this bug.
:jonco, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 2

[Jon Coppeard (:jonco)]

Luke, at the moment I think these are only ever mapped into a single process (but may be shared between multiple runtimes). Is that correct? Are there any plans to change that?

Comment 3

[Luke Wagner [:luke]]

Correct, and there is even an intention not to allow this.

Comment 4

[Jon Coppeard (:jonco)]

Attachment: Bug 1577825 - Refactor zone memory tracker to allow tracking non-GC thing pointers apart from ZoneAllocPolicy r?sfink

This makes the hash table used for tracking ZoneAllocPolicy generic and able to track memory owned by other non-GC things. I'm not entirely sold on the 'other' naming but didn't really like any other alternative I could come up with. The idea is to use this for tracking the memory associated with shared array buffers in the next patch.

Comment 5

[Jon Coppeard (:jonco)]

Attachment: Bug 1577825 - Account for shared array buffer memory r?luke

The challenge here is that the buffers can be shared between zones in different runtimes and also used by more than one SharedArrayBuffer JS object in a zone. The buffers can be large so we want to avoid double-counting. The patch stores a count of the number of SAB objects using a buffer in each zone in a hash table on the SharedArrayRawBuffer. Access is protected by the buffer's mutex to allow this to work when used by different runtimes. This is a bit more heavyweight that I'd have liked, but I figure creating and SAB objects is not going to be a super-hot code path.

Depends on D55533

Comment 6

[Jon Coppeard (:jonco)]

I'll land the first patch now so it doesn't rot.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/f5d3a7653228
Refactor zone memory tracker to allow tracking non-GC thing pointers apart from ZoneAllocPolicy r=sfink

Comment 8

[Daniel Varga [:dvarga]]

https://hg.mozilla.org/mozilla-central/rev/f5d3a7653228

Comment 9

[Jon Coppeard (:jonco)]

Attachment: Bug 1577825 - Account for SharedArrayBuffer memory r?luke

This adds zone methods to account for 'shared' memory, in the sense of shared between more than one GC thing in the zone. The hash map used to track allocations moves to the zone, and we don't have to take a lock. We do need to make the SAB finalizer run on the main thread however (but I think this was going to happen anyway with Lars' patch).

One complication is that the same allocation can be added to the zone with different sizes, when a SAB grows. So we track the size too and update the memory accounting when it increases.

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/f2078bae1c46
Account for SharedArrayBuffer memory r=luke

Comment 11

[Jon Coppeard (:jonco)]

Attachment: Bug 1577825 - Fix build bustage on Windows r?dvarga

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/b70558e9971c
Fix build bustage on Windows a=fix. On a CLOSED TREE

Comment 13

[Cristina Coroiu [:ccoroiu]]

https://hg.mozilla.org/mozilla-central/rev/f2078bae1c46
https://hg.mozilla.org/mozilla-central/rev/b70558e9971c