Dear Maintainer,

Chromium does not work at all on systems with 16k pages.

This commit appears to be the culprit

https://chromium-review.googlesource.com/c/v8/v8/+/5864909

Given that only 16k pagesize systems are affected, this can be worked around for arm64 by applying the following diff to /usr/bin/chromium, without affecting other users.


@@ -64,6 +64,11 @@
             exit 1
         fi
         ;;
+    aarch64)
+        if [ $(getconf PAGESIZE) -gt 4096 ]; then
+            CHROMIUM_FLAGS="$CHROMIUM_FLAGS --js-flags=--no-decommit-pooled-pages"
+        fi
+        ;;
 esac

 # Clean up old crash reports (see https://bugs.debian.org/1015931)

I'm going to quote Tim, who's successfully using 64k pages on ppc64:

"I assume being a 16k page system it's aarch64, which means there is
likely less RAM than this ppc64el machine, and the tab crash described
sounds like v8 or similar running out of memory.  The flag passed also
seems to reinforce that hypothesis.  I'd need to dig into the allocator
to see what that does, since it might also be good to pass on ppc64el if
it doesn't compromise sandboxing or similar -- on ppc64el what I do see
from time to time is that a single tab will "crash" with v8 OOM
(errorcode -5) on certain Javascript-heavy pages, and it could be the
same underlying problem."

Chromium's generally not very good with non-4k page sizes; we're
carrying an allocator patch that we had to add due to hitting asserts()
for 64k pages. Sadly, both the bug report and screenshot are locked down
(thanks google 🙄), so I can't see why they made that
decommit-pooled-pages change.

...

From the history, it appears that this was enabled for better memory
efficiency on WIndows.

When running chromium in the debugger, I hit a trap in that code, and
so I suspect there is some assert() hitting as well, likely due to
decommit logic using a fixed 4k page size.
It is surprising that this doesn't occur on PPC, but as Tim says, this
might simply be due to the lack of memory pressure.