Change:
<ins> --- b/include/clang/Basic/TargetInfo.h +++ a/include/clang/Basic/TargetInfo.h @@ -612,8 +612,8 @@ } /// Return the largest alignment for which a suitably-sized allocation with +  /// '::operator new(size_t)' is guaranteed to produce a correctly-aligned +  /// pointer. -  /// '::operator new(size_t)' or 'malloc' is guaranteed to produce a -  /// correctly-aligned pointer. unsigned getNewAlign() const { return NewAlign ? NewAlign : std::max(LongDoubleAlign, LongLongAlign); } --- b/lib/CodeGen/CGCall.cpp +++ a/lib/CodeGen/CGCall.cpp @@ -2048,24 +2048,6 @@ // allows it to work on indirect virtual function calls. if (AttrOnCallSite && TargetDecl->hasAttr<NoMergeAttr>()) FuncAttrs.addAttribute(llvm::Attribute::NoMerge); - -      // Add known guaranteed alignment for allocation functions. -      if (unsigned BuiltinID = Fn->getBuiltinID()) { -        switch (BuiltinID) { -        case Builtin::BIaligned_alloc: -        case Builtin::BIcalloc: -        case Builtin::BImalloc: -        case Builtin::BImemalign: -        case Builtin::BIrealloc: -        case Builtin::BIstrdup: -        case Builtin::BIstrndup: -          RetAttrs.addAlignmentAttr(Context.getTargetInfo().getNewAlign() / -                                    Context.getTargetInfo().getCharWidth()); -          break; -        default: -          break; -        } -      } } // 'const', 'pure' and 'noalias' attributed functions are also nounwind. --- b/test/CodeGen/alloc-fns-alignment.c +++ /dev/null @@ -1,35 +0,0 @@ -// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-llvm < %s | FileCheck %s --check-prefix=ALIGN16 -// RUN: %clang_cc1 -triple x86_64-windows-msvc      -emit-llvm < %s | FileCheck %s --check-prefix=ALIGN16 -// RUN: %clang_cc1 -triple i386-apple-darwin        -emit-llvm < %s | FileCheck %s --check-prefix=ALIGN16 -// RUN: %clang_cc1 -triple i386-unknown-linux-gnu   -emit-llvm < %s | FileCheck %s --check-prefix=ALIGN8 -// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -fno-builtin-malloc  -emit-llvm < %s  | FileCheck %s --check-prefix=NOBUILTIN-MALLOC -// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -fno-builtin-calloc  -emit-llvm < %s  | FileCheck %s --check-prefix=NOBUILTIN-CALLOC -// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -fno-builtin-realloc -emit-llvm < %s  | FileCheck %s --check-prefix=NOBUILTIN-REALLOC - -typedef __SIZE_TYPE__ size_t; - -void *malloc(size_t); -void *calloc(size_t, size_t); -void *realloc(void *, size_t); - -void *malloc_test(size_t n) { -  return malloc(n); -} - -void *calloc_test(size_t n) { -  return calloc(1, n); -} - -void *raalloc_test(void *p, size_t n) { -  return realloc(p, n); -} - -// ALIGN16: align 16 i8* @malloc -// ALIGN16: align 16 i8* @calloc -// ALIGN16: align 16 i8* @realloc -// ALIGN8: align 8 i8* @malloc -// ALIGN8: align 8 i8* @calloc -// ALIGN8: align 8 i8* @realloc -// NOBUILTIN-MALLOC: declare i8* @malloc -// NOBUILTIN-CALLOC: declare i8* @calloc -// NOBUILTIN-REALLOC: declare i8* @realloc </ins>

Discussion:
Over time, memory consumption increases to about 1 - 1.5 GB per parent process, and does not decrease even after closing all tabs. If you select and close all these tabs, and then open them again, it will easily raise consumption to ~ 800 MB, after that growth slows down. The easiest and fastest way to reproduce this is to open several heavy tabs at the same time. (This list will take up more than six gigabytes at a time after the pages are fully loaded, so be careful). The official nightly build launched via lxd in debian 11, as well as the current version installed via flatpak, is not affected by this problem, in them the main process after the end of loading tabs decreases back to ~300 MB. Here is a fragment of the output to make it clearer what it is about. In this case, you need to pay attention to the consumption of the process. In this case, it is a process . This browser run through flatpak and now it have some opened tabs. Steps to reproduce the behavior: heavy tabs A browser installed via nix should not consume more memory than via flapak or lxd.
Can confirm. Comparing and by opening and closing one of those habr links, the latter eats 600M and doesn't give it back whereas the former frees that memory. I suppose using can be a workaround in some circumstances.
Thanks for reporting this. I assume this is related to our source builds having disabled jemalloc quite recently. I submitted a PR to rectify that. PTAL.
memory consumption went back down for me.
I believe Firefox does not immediately free the memory if you are not under memory pressure so I think this is only a problem if it also causes issues with high system memory usage.
Resolved by , currently on staging-next.
The fix made it into and so I consider this resolved.