From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: X-Spam-Status: No, score=-4.2 required=3.0 tests=ALL_TRUSTED,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF shortcircuit=no autolearn=ham autolearn_force=no version=3.4.6 Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id 8434B1F47C; Fri, 6 Jan 2023 21:59:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=80x24.org; s=selector1; t=1673042349; bh=3AHf+qgRhnddshgFSS3aDMp/c8wgljCh1d+Mt5Cs0/Q=; h=Date:From:To:Cc:Subject:From; b=ZpUq5nXBW/lLLvIGj+ueJ9Lf4O33P7IYu056iAiPZWQHDY3vShpQ/DzLdT7dmdaZ6 SbzGTiVG2vDyG+EzA1df7jLXx4ACAlSh1G8aE06gc9q2FF40XNbBFz9QbC3PpZL7SU GwEyO6eB3ScNaNCjP7MKuMP+oJcaRAML470FG+CE= Date: Fri, 6 Jan 2023 21:59:09 +0000 From: Eric Wong To: mwrap-public@80x24.org Cc: Sam Saffron Subject: dropping Mwrap::HeapPageBody memalign tracking Message-ID: <20230106215909.M940137@dcvr> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline List-Id: Ruby 3.1 switched to mmap for HPB in 2021, and I doubt it'll be going back to *memalign on Linux or FreeBSD. HPB stats don't exist at all for 3.1+ right now. Tracking mmap allocations safely would be significantly more difficult and expensive since munmap can cross mmap-ed regions. With *memalign + free, there's a simple 1:1 relationship, but not with mmap + munmap. munmap can work on any subset (or even superset if multiple mmap calls return sequential pages) of addresses within any mmap-ed region(s). In other words, each 4k page would need a separately-allocated tracking struct in a process-wide tree or hash table. I don't think Ruby currently does asymmetric mmap/munmap; but extensions and any spawned processes may and it's the only safe way to account for it. So the tracking is definitely doable, but I'm not sure it's worth the time and effort. These are GC-internal allocations and any instrumentation for the GC itself is probably better off being added to ruby/gc.c There's something similar on the Perl 5 side, too. It allocates small strings out of 4080-byte malloc-ed arenas and I was confused with 4080-byte allocations until I cranked up C backtraces via MWRAP=bt:$N. I think a better long-term feature would be to be able to interactively crank up C backtrace levels on a per-callsite basis. Right now, the C backtrace level is global, and increasing that interactively gets expensive fast.