[Git][ghc/ghc][wip/marge_bot_batch_merge_job] 5 commits: wasm: bump dyld v8 heap size limit
Marge Bot (@marge-bot)
gitlab at gitlab.haskell.org
Sun Feb 23 13:26:22 UTC 2025
Marge Bot pushed to branch wip/marge_bot_batch_merge_job at Glasgow Haskell Compiler / GHC
Commits:
fbf3d020 by Cheng Shao at 2025-02-22T07:41:01-05:00
wasm: bump dyld v8 heap size limit
This patch sets `--max-old-space-size=65536` as wasm dyld shebang
arguments to lessen v8 heap pressure in certain workloads that load
the full ghc package. It doesn't really commit 64G memory but it does
help reduce v8 gc overhead.
- - - - -
cb60da24 by Cheng Shao at 2025-02-22T07:41:01-05:00
wasm: fix dyld for shared libraries created by llvm 20.x
This patch fixes wasm dyld script for shared libraries created by llvm
20.x. The __wasm_apply_data_relocs function is now optional and may be
omitted for shared libraries without any runtime relocatable data
segments, so only call __wasm_apply_data_relocs when it's present.
- - - - -
7eea38c8 by Cheng Shao at 2025-02-22T07:41:37-05:00
driver: fix wasm backend sysroot lookup logic when -flto is passed
For the wasm target, the driver calls `wasm32-wasi-clang
--print-search-dirs` and finds the sysroot directory that contains
libc.so etc, then passes the directory path to dyld. However, when GHC
is configured with -flto as a part of C/C++ compiler flags, the clang
driver would insert a llvm-lto specific directory in the
--print-search-dirs output and the driver didn't take that into
account. This patch fixes it and always selects the non-lto sysroot
directory to be passed to dyld. This is one small step towards
supporting building all cbits with lto for wasm.
- - - - -
982dce46 by Cheng Shao at 2025-02-23T08:26:15-05:00
wasm: add Note [Variable passing in JSFFI] as !13583 follow up
This patch adds a note to explain how the magic variables like
`__ghc_wasm_jsffi_dyld` are brought into scope of JSFFI code snippets,
as follow up work of !13583.
- - - - -
2ab45438 by Cheng Shao at 2025-02-23T08:26:15-05:00
libffi: update to 3.4.7
Bumps libffi submodule.
- - - - -
5 changed files:
- compiler/GHC.hs
- libffi-tarballs
- libraries/ghci/GHCi/ObjLink.hs
- utils/jsffi/dyld.mjs
- utils/jsffi/post-link.mjs
Changes:
=====================================
compiler/GHC.hs
=====================================
@@ -717,11 +717,7 @@ setTopSessionDynFlags dflags = do
#if defined(wasm32_HOST_ARCH)
let libdir = sorry "cannot spawn child process on wasm"
#else
- libdir <- liftIO $ do
- libdirs <- Loader.getGccSearchDirectory logger dflags "libraries"
- case libdirs of
- [_, libdir] -> pure libdir
- _ -> panic "corrupted wasi-sdk installation"
+ libdir <- liftIO $ last <$> Loader.getGccSearchDirectory logger dflags "libraries"
#endif
let profiled = ways dflags `hasWay` WayProf
way_tag = if profiled then "_p" else ""
=====================================
libffi-tarballs
=====================================
@@ -1 +1 @@
-Subproject commit 89a9b01c5647c8f0d3899435b99df690f582e9f1
+Subproject commit cb280851187d7b509d341be7b50c9a239810feb0
=====================================
libraries/ghci/GHCi/ObjLink.hs
=====================================
@@ -76,6 +76,9 @@ loadDLL f =
evaluate =<< js_loadDLL (toJSString f)
pure $ Right nullPtr
+-- See Note [Variable passing in JSFFI] for where
+-- __ghc_wasm_jsffi_dyld comes from
+
foreign import javascript safe "__ghc_wasm_jsffi_dyld.loadDLL($1)"
js_loadDLL :: JSString -> IO ()
=====================================
utils/jsffi/dyld.mjs
=====================================
@@ -1,4 +1,4 @@
-#!/usr/bin/env -S node --disable-warning=ExperimentalWarning --experimental-wasm-type-reflection --max-old-space-size=8192 --no-turbo-fast-api-calls --wasm-lazy-validation
+#!/usr/bin/env -S node --disable-warning=ExperimentalWarning --experimental-wasm-type-reflection --max-old-space-size=65536 --no-turbo-fast-api-calls --wasm-lazy-validation
// Note [The Wasm Dynamic Linker]
// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -629,7 +629,8 @@ class DyLD {
// Fulfill the ghc_wasm_jsffi imports. Use new Function()
// instead of eval() to prevent bindings in this local scope to
- // be accessed by JSFFI code snippets.
+ // be accessed by JSFFI code snippets. See Note [Variable passing in JSFFI]
+ // for what's going on here.
Object.assign(
import_obj.ghc_wasm_jsffi,
new Function(
@@ -796,12 +797,17 @@ class DyLD {
const init = () => {
// See
- // https://github.com/llvm/llvm-project/blob/llvmorg-19.1.1/lld/wasm/Writer.cpp#L1430,
- // there's also __wasm_init_memory (not relevant yet, we don't
+ // https://gitlab.haskell.org/haskell-wasm/llvm-project/-/blob/release/20.x/lld/wasm/Writer.cpp#L1450,
+ // __wasm_apply_data_relocs is now optional so only call it if
+ // it exists (we know for sure it exists for libc.so though).
+ // There's also __wasm_init_memory (not relevant yet, we don't
// use passive segments) & __wasm_apply_global_relocs but
// those are included in the start function and should have
- // been called upon instantiation.
- instance.exports.__wasm_apply_data_relocs();
+ // been called upon instantiation, see
+ // Writer::createStartFunction().
+ if (instance.exports.__wasm_apply_data_relocs) {
+ instance.exports.__wasm_apply_data_relocs();
+ }
instance.exports._initialize();
};
=====================================
utils/jsffi/post-link.mjs
=====================================
@@ -52,6 +52,47 @@ export function parseSections(mod) {
return recs;
}
+// Note [Variable passing in JSFFI]
+// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+//
+// The JSFFI code snippets can access variables in globalThis,
+// arguments like $1, $2, etc, plus a few magic variables: __exports,
+// __ghc_wasm_jsffi_dyld and __ghc_wasm_jsffi_finalization_registry.
+// How are these variables passed to JSFFI code? Remember, we strive
+// to keep the globalThis namespace hygiene and maintain the ability
+// to have multiple Haskell-wasm apps coexisting in the same JS
+// context, so we must not pass magic variables as global variables
+// even though they may seem globally unique.
+//
+// The solution is simple: put them in the JS lambda binder position.
+// Though there are different layers of lambdas here:
+//
+// 1. User writes "$1($2, await $3)" in a JSFFI code snippet. No
+// explicit binder here, the snippet is either an expression or
+// some statements.
+// 2. GHC doesn't know JS syntax but it knows JS function arity from
+// HS type signature, as well as if the JS function is async/sync
+// from safe/unsafe annotation. So it infers the JS binder (like
+// "async ($1, $2, $3)") and emits a (name,binder,body) tuple into
+// the ghc_wasm_jsffi custom section.
+// 3. After link-time we collect these tuples to make a JS object
+// mapping names to binder=>body, and this JS object will be used
+// to fulfill the ghc_wasm_jsffi wasm imports. This JS object is
+// returned by an outer layer of lambda which is in charge of
+// passing magic variables.
+//
+// In case of post-linker for statically linked wasm modules,
+// __ghc_wasm_jsffi_dyld won't work so is omitted, and
+// __ghc_wasm_jsffi_finalization_registry can be created inside the
+// outer JS lambda. Only __exports is exposed as user-visible API
+// since it's up to the user to perform knot-tying by assigning the
+// instance exports back to the (initially empty) __exports object
+// passed to this lambda.
+//
+// In case of dyld, all magic variables are dyld-session-global
+// variables; dyld uses new Function() to make the outer lambda, then
+// immediately invokes it by passing the right magic variables.
+
export async function postLink(mod) {
let src = (
await fs.readFile(path.join(import.meta.dirname, "prelude.mjs"), {
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/b06294507456231391b91f17316bb0312f2de752...2ab4543868d60cdfffde5d55e6e4680211d3bfd2
--
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/b06294507456231391b91f17316bb0312f2de752...2ab4543868d60cdfffde5d55e6e4680211d3bfd2
You're receiving this email because of your account on gitlab.haskell.org.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-commits/attachments/20250223/340da684/attachment-0001.html>
More information about the ghc-commits
mailing list