1861991 - Bad mutex contention when allocating strings in JSON.parse() in TodoMVC-Javascript-ES6-Webpack on Android

Status: NEW

(Core :: Performance, defect)

Description

[Jamie Nicol [:jnicol] out of office until 6th Jan]

Profile: https://share.firefox.dev/3tZ0KNq

This is allocating from the js::StringBufferArena arena in NewStringCopyNDontDeflateNonStaticValidLength()

I don't see nearly the same amount of contention in the windows profiles

Comment 1

[Jeff Muizelaar [:jrmuizel]]

It looks like the contention is caused by js::gc::BackgroundFreeTask::run
https://share.firefox.dev/478LdsW

Comment 2

[Jamie Nicol [:jnicol] out of office until 6th Jan]

Yeah had noticed that, which could explain why we at one point saw wins from bug 1850231. (But perhaps the downsides of disabling background tasks cancels it out enough that the win is inconclusive)

Comment 3

[Jamie Nicol [:jnicol] out of office until 6th Jan]

I think this is probably mostly due to samply not handling off-cpu samples correctly.

Here are two profiles, both converted from the same perf.json which was captured using simpleperf with --trace-offcpu. The first was converted using a samply which doesn't understand simpleperf's off-cpu data correctly, like the original profile I posted in comment 0. The second was converted using a samply I've patched to interpret the off-cpu data correctly.

Without samply fix: https://share.firefox.dev/49hX2yz
With samply fix: https://share.firefox.dev/49leZN1

Without the fix we see a huge amount of time spent in the kernel's schedule(), hence why I filed this bug. But with the fix the kernel time is almost completely gone. We see a slight increase in the self time in syscall() when we are off cpu, but it's not indicative of a major issue. This matches what we see in the windows profiles.

It's a mystery to me why we see so much time in schedule() without the fix, though.