1825159 - Javascript info missing in about:support

Status: UNCONFIRMED

(Toolkit :: General, enhancement, P5)

Description

[Dimitrios Apostolou]

User Agent: Mozilla/5.0 (X11; Linux aarch64; rv:102.0) Gecko/20100101 Firefox/102.0

Steps to reproduce:

I'm trying to debug extreme javascript (and asm.js) slowness on a non x86 platform. My suspicion is that Javascript is bytecode-interpreted and none of the optimizing compilers are working. Unfortunately I can't find a way to verify this.

Ideally about:support would contain a "javascript" session that would list all the different levels of javascript engines (baseline interpreter, JIT compiler, tracemonkey, ionmonkey etc) and their status (enabled/disabled). Also whether WASM execution is supported.

Comment 1

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

The Bugbug bot thinks this bug should belong to the 'Core::JavaScript Engine' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Iain Ireland [:iain]]

This page has some (hopefully useful) information about Mozilla's support for various architectures. Since the answer to "does JS run on this platform?" is "yes" for every platform that Mozilla actively supports, we're unlikely to add a section to about:support to document that fact.

SpiderMonkey supports x86 and ARM (32 and 64 bit in both cases) as tier-1 architectures. We also have external contributors who maintain in-tree JIT support for Loongson and RISC-V (64-bit only). We still have code for 32 and 64 bit MIPS, but it's bitrotted and will likely be deleted. There's a partial PowerPC port floating around somewhere, but it's never been part of mozilla-central.

If your architecture is not on that list, your JS code will run entirely in the interpreter.

Hope this helps!

Comment 3

[Dimitrios Apostolou]

My platform is "armhf". In particular Raspberry Pi OS default image (32-bit AR), with firefox-esr installed from the repositories.

Chromium is the default and very usable browser on this platform. Firefox is almost unusable, very laggy and completely freezing on javascript-heavy websites.

But this ticket is not about the slowness on armhf. It is about how to debug the slowness. I have been running some custom javascript oneliners trying to figure out the speed, but other than that, I see no indication in debug logs, javascript console, about: support or buildconfig.

Since the answer to "does JS run on this platform?" is "yes" for every platform that Mozilla actively supports, we're unlikely to add a section to about:support to document that fact.

I guess Mozilla supports its own builds. Since there are many custom (distribution) builds, it would be useful to have a way to check available optimisations. This way distributors can optimise their compile flags, maybe even tweak the target architecture. It is useful for bugreports too. I can open a new ticket reporting "extreme slowness" but how would you figure out what slows javascript down?

Comment 4

[Iain Ireland [:iain]]

Your best bet may be to find the maintainer of the raspbian package.

glandium, I poked around in the raspbian repository and your name showed up in the "Uploaders" field for firefox-esr. Not sure if that has anything to do with raspbian specifically or if it's just carried over from regular Debian. Do you know who is responsible for packaging this build?

Comment 5

[Iain Ireland [:iain]]

Huh, that's the second time in a few weeks where I've accidentally closed a bug. Not sure if there's some UI issue or if I'm just bad at clicking.

Comment 6

[Mike Hommey [:glandium]]

Linux armhf is more or less the same as the ARM variant supported for Android (the main difference between NEON being optional on Linux armhf), so presumably the JIT support is the same.

That said, I could see it being useful to have this information in about:support because it would be easier than trying to figure out whether some levels were disabled at build time, via prefs, or because platform support is absent (also, I think on some platforms, the JIT may disable itself if some instructions are not available at runtime)

Comment 7

[Dimitrios Apostolou]

I have also noticed that WASM code is not executed directly, but translated to asm.js and then executed (very slowly).

So another thing to add to about:support would be if WASM execution is supported.

Comment 8

[Matthew Gaudet (he/him) [:mgaudet]]

(moving to Toolkit :: General as that seems to be the about:support component?)