Re: [blfs-dev] js78 and jemalloc
On Tue, Sep 22, 2020 at 01:48:27AM +0800, Xi Ruoyao via blfs-dev wrote: > On 2020-09-21 17:59 +0100, Ken Moffat via blfs-dev wrote: > > On Mon, Sep 21, 2020 at 10:07:18AM -0500, Douglas R. Reno via blfs-dev > > wrote: > > > > > > On 9/21/20 9:36 AM, Ken Moffat via blfs-dev wrote: > > > > I'm now looking at js78 because firefox-78.3.0 is out. For the > > > > moment I'm still using js68, but I can at least compare the js build > > > > against 78.2.0. > > > > > > > > Looking at that, we have '--disable-jemalloc' with the explanation: > > > > This switch disables the internal memory allocator used in JS78. > > > > jemalloc causes a conflict with glibc. > > > > > > [...] > > > > I've now looked at fedora, > > > > https://src.fedoraproject.org/rpms/mozjs78/blob/master/f/mozjs78.spec > > > > > > > > It seems to me that they are not disabling jemalloc. > > They are: > > > https://src.fedoraproject.org/rpms/mozjs78/blob/master/f/mozjs78.spec#_158 > I searched in firefox for jemalloc on my that specfile on my other machine and didn't get any matches. Probably I typo'd. Thanks for the link, and the extra wording is a lot clearer. > > > > I think dropping --disable-jemalloc is a good idea. I think that's a > > > holdover from when we first added it, I think js60 or js52? It was around > > > the time that Gjs started requiring later versions of the Spidermonkey JS > > > engine. > > > > > > - Doug > > > > > > > Thanks. I've remeasured without it (faster, but might be normal rust > > variation), will do that. > > From > https://github.com/mozilla-spidermonkey/spidermonkey-embedding-examples/blob/esr78/docs/Building%20SpiderMonkey.md > ： > > > Disabling jemalloc > > > > One important configuration when getting started is the --disable-jemalloc > > flag. This will cause SpiderMonkey to use the system allocator functions > > instead of a custom build of jemalloc. The custom configuration, which is > > the > > default, is intended for a browser environment and requires linking the > > final > > application with a matching version of a library called mozglue. If one > > accidentally builds SpiderMonkey for their embedding without including the > > -- > > disable-jemalloc flag, they usually quickly encounter strange crashes as > > items > > allocated in jemalloc allocator are freed on system allocator. > > So don't do that. You caught it just in time ;-) ĸen -- A really good hydrophobe has to be trained on dehydrated water from birth. I mean, that costs a fortune in magic alone. But they make great weather magicians. Rain clouds just give up and go away. -- The Colour of Magic -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] js78 and jemalloc
On 2020-09-21 17:59 +0100, Ken Moffat via blfs-dev wrote: > On Mon, Sep 21, 2020 at 10:07:18AM -0500, Douglas R. Reno via blfs-dev wrote: > > > > On 9/21/20 9:36 AM, Ken Moffat via blfs-dev wrote: > > > I'm now looking at js78 because firefox-78.3.0 is out. For the > > > moment I'm still using js68, but I can at least compare the js build > > > against 78.2.0. > > > > > > Looking at that, we have '--disable-jemalloc' with the explanation: > > > This switch disables the internal memory allocator used in JS78. > > > jemalloc causes a conflict with glibc. > > > > [...] > > > I've now looked at fedora, > > > https://src.fedoraproject.org/rpms/mozjs78/blob/master/f/mozjs78.spec > > > > > > It seems to me that they are not disabling jemalloc. They are: https://src.fedoraproject.org/rpms/mozjs78/blob/master/f/mozjs78.spec#_158 > > > I think dropping --disable-jemalloc is a good idea. I think that's a > > holdover from when we first added it, I think js60 or js52? It was around > > the time that Gjs started requiring later versions of the Spidermonkey JS > > engine. > > > > - Doug > > > > Thanks. I've remeasured without it (faster, but might be normal rust > variation), will do that. From https://github.com/mozilla-spidermonkey/spidermonkey-embedding-examples/blob/esr78/docs/Building%20SpiderMonkey.md ： > Disabling jemalloc > > One important configuration when getting started is the --disable-jemalloc > flag. This will cause SpiderMonkey to use the system allocator functions > instead of a custom build of jemalloc. The custom configuration, which is the > default, is intended for a browser environment and requires linking the final > application with a matching version of a library called mozglue. If one > accidentally builds SpiderMonkey for their embedding without including the -- > disable-jemalloc flag, they usually quickly encounter strange crashes as items > allocated in jemalloc allocator are freed on system allocator. So don't do that. -- Xi Ruoyao School of Aerospace Science and Technology, Xidian University -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] js78 and jemalloc
On Mon, Sep 21, 2020 at 10:07:18AM -0500, Douglas R. Reno via blfs-dev wrote: > > On 9/21/20 9:36 AM, Ken Moffat via blfs-dev wrote: > > I'm now looking at js78 because firefox-78.3.0 is out. For the > > moment I'm still using js68, but I can at least compare the js build > > against 78.2.0. > > > > Looking at that, we have '--disable-jemalloc' with the explanation: > > This switch disables the internal memory allocator used in JS78. > > jemalloc causes a conflict with glibc. > > [...] > > I've now looked at fedora, > > https://src.fedoraproject.org/rpms/mozjs78/blob/master/f/mozjs78.spec > > > > It seems to me that they are not disabling jemalloc. > > > > ĸen > > I think dropping --disable-jemalloc is a good idea. I think that's a > holdover from when we first added it, I think js60 or js52? It was around > the time that Gjs started requiring later versions of the Spidermonkey JS > engine. > > - Doug > Thanks. I've remeasured without it (faster, but might be normal rust variation), will do that. ĸen -- A really good hydrophobe has to be trained on dehydrated water from birth. I mean, that costs a fortune in magic alone. But they make great weather magicians. Rain clouds just give up and go away. -- The Colour of Magic -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] js78 and jemalloc
On 9/21/20 9:36 AM, Ken Moffat via blfs-dev wrote: I'm now looking at js78 because firefox-78.3.0 is out. For the moment I'm still using js68, but I can at least compare the js build against 78.2.0. Looking at that, we have '--disable-jemalloc' with the explanation: This switch disables the internal memory allocator used in JS78. jemalloc causes a conflict with glibc. I suspect we have carried that for a long time, but I think it is now out of date. I am in the middle of playing with blender (a maze of nasty cmake packages, a couple of which can use jemalloc). When I first tried blender a few months ago, I avoided jemalloc (trying to get a build of as little as possible, for 3D rendering). At that time I only had 16GB DRAM, less the amount used for video, and even for 'barbershop' with only a couple of terms I was into swap so I gave up trying to learn how to use blender. Now I have 32GB on one machine, so I retried. One of the questions was whether I should use jemalloc: the answer was yes, on this machine the memory usage for barbeshop goes down dramatically. As part of that investigation I discovered that firefox DOES use its own local copy of jemalloc when configuring js: 0:22.50 js/src> running /scratch/working/firefox-78.3.0/configure.py --enable-project=js --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu MOZILLA_OFFICIAL= MOZBUILD_STATE_PATH=/scratch/working/firefox-78.3.0/mozbuild --disable-tests --disable-debug --without-debug-label --disable-rust-debug MOZ_PGO= --enable-release --disable-optimize --without-ccache CCACHE_PREFIX= RUSTC_WRAPPER= --without-toolchain-prefix --disable-debug-symbols --disable-address-sanitizer --disable-memory-sanitizer --disable-thread-sanitizer --disable-undefined-sanitizer --disable-signed-overflow-sanitizer --disable-unsigned-overflow-sanitizer --enable-frame-pointers --disable-coverage RUSTC_OPT_LEVEL=2 --enable-cargo-incremental --disable-linker AS= --disable-clang-plugin --disable-clang-plugin-alpha --disable-mozsearch-plugin --disable-stdcxx-compat --disable-fuzzing --disable-cpp-rtti --enable-jemalloc --disable-replace-malloc --without-linux-headers --disable-warnings-as-errors --disable-profile-generate --disable-profile-use --without-pgo-profile-path --disable-lto MOZ_LD64_KNOWN_GOOD= --enable-new-pass-manager --disable-valgrind --disable-smoosh --with-system-nspr RUSTC= CARGO= RUSTDOC= RUSTFMT= --without-libclang-path --without-clang-path BINDGEN_CFLAGS= --disable-js-shell --enable-jit --disable-simulator --disable-instruments --disable-callgrind --disable-profiling --disable-vtune --disable-gc-probes --disable-gczeal --disable-small-chunk-size --disable-trace-logging --disable-oom-breakpoint --disable-perf --disable-jitspew --disable-masm-verbose --disable-more-deterministic --enable-ctypes --with-system-ffi --disable-pipeline-operator --disable-binast --disable-rust-simd --disable-cranelift --disable-wasm-codegen-debug --disable-typed-objects --disable-wasm-bulk-memory --disable-wasm-reftypes --disable-wasm-gc --disable-wasm-private-reftypes --enable-wasm-multi-value --enable-shared-memory --enable-new-regexp --disable-wasm-simd --without-qemu-exe --with-cross-lib=/usr/x86_64-pc-linux-gnu --without-sixgill --with-jitreport-granularity=3 --with-system-icu --with-intl-api --disable-dtrace --enable-icf --disable-strip --enable-install-strip STRIP_FLAGS= --with-system-zlib --prefix=/scratch/working/firefox-78.3.0/firefox-build-dir/dist JS_STANDALONE= and then one further reference: 12:35.42 [style 0.0.1] cargo:rerun-if-changed=/scratch/working/firefox-78.3.0/firefox-build-dir/dist/include/mozjemalloc_types.h I've now looked at fedora, https://src.fedoraproject.org/rpms/mozjs78/blob/master/f/mozjs78.spec It seems to me that they are not disabling jemalloc. ĸen I think dropping --disable-jemalloc is a good idea. I think that's a holdover from when we first added it, I think js60 or js52? It was around the time that Gjs started requiring later versions of the Spidermonkey JS engine. - Doug -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] js78 and jemalloc
I'm now looking at js78 because firefox-78.3.0 is out. For the moment I'm still using js68, but I can at least compare the js build against 78.2.0. Looking at that, we have '--disable-jemalloc' with the explanation: This switch disables the internal memory allocator used in JS78. jemalloc causes a conflict with glibc. I suspect we have carried that for a long time, but I think it is now out of date. I am in the middle of playing with blender (a maze of nasty cmake packages, a couple of which can use jemalloc). When I first tried blender a few months ago, I avoided jemalloc (trying to get a build of as little as possible, for 3D rendering). At that time I only had 16GB DRAM, less the amount used for video, and even for 'barbershop' with only a couple of terms I was into swap so I gave up trying to learn how to use blender. Now I have 32GB on one machine, so I retried. One of the questions was whether I should use jemalloc: the answer was yes, on this machine the memory usage for barbeshop goes down dramatically. As part of that investigation I discovered that firefox DOES use its own local copy of jemalloc when configuring js: 0:22.50 js/src> running /scratch/working/firefox-78.3.0/configure.py --enable-project=js --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu MOZILLA_OFFICIAL= MOZBUILD_STATE_PATH=/scratch/working/firefox-78.3.0/mozbuild --disable-tests --disable-debug --without-debug-label --disable-rust-debug MOZ_PGO= --enable-release --disable-optimize --without-ccache CCACHE_PREFIX= RUSTC_WRAPPER= --without-toolchain-prefix --disable-debug-symbols --disable-address-sanitizer --disable-memory-sanitizer --disable-thread-sanitizer --disable-undefined-sanitizer --disable-signed-overflow-sanitizer --disable-unsigned-overflow-sanitizer --enable-frame-pointers --disable-coverage RUSTC_OPT_LEVEL=2 --enable-cargo-incremental --disable-linker AS= --disable-clang-plugin --disable-clang-plugin-alpha --disable-mozsearch-plugin --disable-stdcxx-compat --disable-fuzzing --disable-cpp-rtti --enable-jemalloc --disable-replace-malloc --without-linux-headers --disable-warnings-as-errors --disable-profile-generate --disable-profile-use --without-pgo-profile-path --disable-lto MOZ_LD64_KNOWN_GOOD= --enable-new-pass-manager --disable-valgrind --disable-smoosh --with-system-nspr RUSTC= CARGO= RUSTDOC= RUSTFMT= --without-libclang-path --without-clang-path BINDGEN_CFLAGS= --disable-js-shell --enable-jit --disable-simulator --disable-instruments --disable-callgrind --disable-profiling --disable-vtune --disable-gc-probes --disable-gczeal --disable-small-chunk-size --disable-trace-logging --disable-oom-breakpoint --disable-perf --disable-jitspew --disable-masm-verbose --disable-more-deterministic --enable-ctypes --with-system-ffi --disable-pipeline-operator --disable-binast --disable-rust-simd --disable-cranelift --disable-wasm-codegen-debug --disable-typed-objects --disable-wasm-bulk-memory --disable-wasm-reftypes --disable-wasm-gc --disable-wasm-private-reftypes --enable-wasm-multi-value --enable-shared-memory --enable-new-regexp --disable-wasm-simd --without-qemu-exe --with-cross-lib=/usr/x86_64-pc-linux-gnu --without-sixgill --with-jitreport-granularity=3 --with-system-icu --with-intl-api --disable-dtrace --enable-icf --disable-strip --enable-install-strip STRIP_FLAGS= --with-system-zlib --prefix=/scratch/working/firefox-78.3.0/firefox-build-dir/dist JS_STANDALONE= and then one further reference: 12:35.42 [style 0.0.1] cargo:rerun-if-changed=/scratch/working/firefox-78.3.0/firefox-build-dir/dist/include/mozjemalloc_types.h I've now looked at fedora, https://src.fedoraproject.org/rpms/mozjs78/blob/master/f/mozjs78.spec It seems to me that they are not disabling jemalloc. ĸen -- A really good hydrophobe has to be trained on dehydrated water from birth. I mean, that costs a fortune in magic alone. But they make great weather magicians. Rain clouds just give up and go away. -- The Colour of Magic -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
