• Austin Clements's avatar
    runtime: split object finding out of heapBitsForObject · 058bb7ea
    Austin Clements authored
    heapBitsForObject does two things: it finds the base of the object and
    it creates the heapBits for the base of the object. There are several
    places where we just care about the base of the object. Furthermore,
    greyobject only needs the heapBits in the checkmark path and can
    easily compute them only when needed. Once we eliminate passing the
    heap bits to grayobject, almost all uses of heapBitsForObject don't
    need the heap bits.
    
    Hence, this splits heapBitsForObject into findObject and
    heapBitsForAddr (the latter already exists), removes the hbits
    argument to grayobject, and replaces all heapBitsForObject calls with
    calls to findObject.
    
    In addition to making things cleaner overall, heapBitsForAddr is going
    to get more expensive shortly, so it's important that we don't do it
    needlessly.
    
    Note that there's an interesting performance pitfall here. I had
    originally moved findObject to mheap.go, since it made more sense
    there. However, that leads to a ~2% slow down and a whopping 11%
    increase in L1 icache misses on both the x/garbage and compilebench
    benchmarks. This suggests we may want to be more principled about
    this, but, for now, let's just leave findObject in mbitmap.go.
    
    (I tried to make findObject small enough to inline by splitting out
    the error case, but, sadly, wasn't quite able to get it under the
    inlining budget.)
    
    Change-Id: I7bcb92f383ade565d22a9f2494e4c66fd513fb10
    Reviewed-on: https://go-review.googlesource.com/85878
    Run-TryBot: Austin Clements <austin@google.com>
    TryBot-Result: Gobot Gobot <gobot@golang.org>
    Reviewed-by: 's avatarRick Hudson <rlh@golang.org>
    058bb7ea
mfinal.go 14.8 KB