[HN Gopher] Low Overhead Allocation Sampling in a Garbage Collec...
       ___________________________________________________________________
        
       Low Overhead Allocation Sampling in a Garbage Collected Virtual
       Machine
        
       Author : matt_d
       Score  : 9 points
       Date   : 2025-06-23 06:26 UTC (3 days ago)
        
 (HTM) web link (arxiv.org)
 (TXT) w3m dump (arxiv.org)
        
       | finnh wrote:
       | > Enabling allocation sampling profiling with a sampling period
       | of 4 MB leads to a maximum time overhead of 25% in our
       | benchmarks, over un-profiled regular execution
       | 
       | 25% is not low overhead, but perhaps this example is the worse
       | case and other tunings actually are low overhead. There's no
       | exact definition I don't think, but anything much over 3% starts
       | to feel like a lot of overhead to me.
       | 
       | Reading on:
       | 
       | > Our main technical insight is that the check whether an
       | allocation should be sampled can be made free. This is done by
       | folding it into the bump-pointer allocator check that PyPy's GC
       | uses to find out if it should start a minor collection. In this
       | way the fast path with and without memory sampling are exactly
       | the same.
       | 
       | That is cool, and means you only pay for the samples you produce
       | = something you could leave enabled confidently, with a low-
       | enough sample rate at least.
        
       | randomNumber7 wrote:
       | Just use Rust then you don't need a garbage collector /S
        
       ___________________________________________________________________
       (page generated 2025-06-26 23:00 UTC)