Repository navigation
Is it possible to detect kAddressBits at runtime? #82
Description
Activity
It would be possible to make
kAddressBitsbe runtime configurable (albeit at a slight performance cost, since we'd need to load the constant rather than use an immediate)--but I think one challenge is reliably detecting the value at runtime.Other than reading
/proc/config.gz--which would be a bit involved while allocating memory--the only strategy that I'm aware of seems to be trial and error. I seem to recall a proposed kernel patch that would have exposed it (maybe as a proc file?) but I don't think it ever landed.maybe the following does help: openjdk/jdk#40
And the thread on the topic: http://openjdk.5641.n7.nabble.com/ZGC-aarch64-Unable-to-allocate-heap-for-certain-Linux-kernel-configurations-td420728.htmlI think this is how the folks ad openjdk are handling it by trial and error.
+1 after struggling with a mysterious SIGABRT for a whole day and finally finding this issue. As a low-level library, tcmalloc may be depended by projects whose developers even don't know its existence. If detect the correct value of
kAddressBitsis hard, could we detect whetherkAddressBitsis misconfigured at runtime so we can abort in a more user-friendly way?Reacted by Philipp Kolberg, Michael Ramstein, Jesse Gibson, vbohinc, James Olds, Damià Poquet Femenia, frodera and BraxtonAs checking for the kernel build config in
/proc/config.gzrequiresCONFIG_IKCONFIG_PROCto be set, the best option would be for tcmalloc to use the proposed trial and error approach. Also a way to manually forcekAddressBitsto be set during compilation would be appreciated (without any automatic detection).- added a commit that references this issue
on Feb 22, 2023 Code that detects the address space size.. https://github.com/ptitSeb/box64/blob/e42001b2bc030f93bdba582bf12d6eac63fae345/src/custommem.c#L1444
Reacted by Philipp Kolberg, Jesse Gibson, Danny Althoff and Jef SpaletaV8 does a best-effort runtime detection (with fallback to compile time constants) for determining virtual address space size, can something similar be tried in tcmalloc during initialization?
https://github.com/v8/v8/blob/14.1-lkgr/src/sandbox/sandbox.cc#L39-L99
Reacted by Tristan Morgan
As noted in #33 page tables on Aarch64 can have either 3 or 4 levels. tcmalloc assumes 4 levels for Aarch64 (kAddressBits = 48), but for example RaspberryOS for Aarch64 runs on a kernel with
CONFIG_PGTABLE_LEVELS=3. As result all programs using tcmalloc fail without patching it to set kAddressBits = 39.Is it possible to detect
kAddressBitsat runtime?