1824655 - Investigate skipping locking for the DOM jemalloc arena

Status: RESOLVED FIXED

(Core :: Memory Allocator, task, P2)

Description

[Paul Bone [:pbone]]

Smaug suggested we could disable locking for the jemalloc arenas created by DOMArena since they're only ever accessed from the main thread.

I tried it and found that it hasn't changed a whole lot for most tests. Indeed in speedometer it'd be a tiny fraction of the total runtime that we spend acquiring the lock.

https://treeherder.mozilla.org/perfherder/compare?originalProject=try&originalRevision=0a87812741f757733c11a01766326cce5d014012&newProject=try&newRevision=c658aacc240983073c3838e29a6d5a27068bf585&framework=13&page=1&showOnlyConfident=1

I had another test that timed how long it takes to get a lock and was showing >20ns for these completely uncontested locks. It turns out that that's roughly the time recorded for two consecutive clock_gettime(CLOCK_MONOTONIC_RAW, &time) calls on Linux (which I assume use the TSC). So the uncontested locks are definitly fast enough, at least for Pthreads on Linux.

I'm filing this bug to record these results in case anyone is curious in the future, not because it's code I actually want to land. I'll add a patch with the code I tested.

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

https://treeherder.mozilla.org/perfherder/comparesubtest?originalProject=try&newProject=try&newRevision=c658aacc240983073c3838e29a6d5a27068bf585&originalSignature=4586009&newSignature=4586009&framework=13&application=firefox&originalRevision=0a87812741f757733c11a01766326cce5d014012&page=1&showOnlyConfident=1 shows the changes discussed in Matrix. This seems to be useful for some DOM heavy sp3 tests.

Comment 2

[Paul Bone [:pbone]]

Attachment: Bug 1824655 - Avoid locking for the DOMArena jemalloc arena r=smaug,glandium

Depends on D173827

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

Since sp3 keeps changing, I was curious to see how this affects atm.
Especially some DOM heavy tests on linux like this https://treeherder.mozilla.org/perfherder/comparesubtest?originalProject=try&newProject=try&newRevision=f3d87788e74a3b0a2411b52eb25c2ec984c38d52&originalSignature=4569240&newSignature=4569240&framework=13&application=firefox&originalRevision=ee4461e87f74637b1c07730143b2ff3659d93e01&page=1&showOnlyConfident=1

Comment 4

[Paul Bone [:pbone]]

I ran performance tests (because I was also checking Bug 1810953 https://treeherder.mozilla.org/perfherder/compare?originalProject=try&originalRevision=9d839a73e147d5c632b77e115503bc41665efa34&newProject=try&newRevision=8369603144df912ca38ad34c6d6d79f03df8114b&framework=13&page=1&filter=speedometer

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

Hmm, no changes on Windows. But some subtests on linux still like this quite a bit.

Comment 6

[Paul Bone [:pbone]]

Maybe the locks we use on Windows are just faster anyway?

So with making these main-thread-only arenas, there are some parts of our code that call jemalloc_stats from off-thread. It can't read the stats from the arenas safely so I'm working on a fix for that.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/35d7297c823c
Avoid locking for the DOMArena jemalloc arena r=smaug

Comment 8

[Atila Butkovits]

https://hg.mozilla.org/mozilla-central/rev/35d7297c823c