296902 2025-08-04 15:55:12 -0700 [libpas] bmalloc_heap.h should support aligned-zeroed allocations 2025-08-08 16:48:51 -0700 1 1 1 Unclassified WebKit bmalloc WebKit Nightly Build Unspecified Unspecified RESOLVED FIXED InRadar P2 Normal --- 1 marcus_plutowski webkit-unassigned ggaren webkit-bug-importer oldest_to_newest 2134285 0 marcus_plutowski 2025-08-04 15:55:12 -0700 rdar://157510912 Currently, we support both aligned allocations (e.g. bmalloc_allocate_with_alignment) and zeroed allocations (e.g. bmalloc_allocate_zeroed); however, we do not support simultaneously-aligned-and-zeroed allocations (e.g. bmalloc_allocate_zeroed_with_alignment). The consumer of the API can just zero it themselves, but libpas is careful to optimize out that zeroing operation if it knows it’s not necessary, e.g. if the page was newly mmap’d (c.f. pas_allocation_result_zero). This comes up when allocating wasm memory, as we basically 1. Ask for a huge allocation 2. Mmap over it to ensure it’s zero This is probably not itself a huge performance problem, but it does show up when I tried to switch that #2 over to madvise(MADV_ZERO): normally this would be preferable because this subsequent mmap would fragment the backing vm-objects (and acquire more locks), but in the case that we’re just replacing the entire vm-object anyways the first downside goes away, while the actual effort of going page-by-page and making sure they’re zeroed begins to dominate. Creating this new bmalloc_allocate_zeroed_with_alignment family of functions will allow us to avoid that unnecessary mmap and unblock migrating it to use madvise(MADV_ZERO) instead. 2134294 1 marcus_plutowski 2025-08-04 16:05:35 -0700 Pull request: https://github.com/WebKit/WebKit/pull/48928 2135344 2 ews-feeder 2025-08-08 16:48:50 -0700 Committed 298428@main (2ea1c1850d3a): <https://commits.webkit.org/298428@main> Reviewed commits have been landed. Closing PR #48928 and removing active labels.