Skip to content
  • Alan Wu's avatar
    a0b0365e
    YJIT: Deallocate `struct Block` to plug memory leaks · a0b0365e
    Alan Wu authored
    Previously we essentially never freed block even after invalidation.
    Their reference count never reached zero for a couple of reasons:
    1. `Branch::block` formed a cycle with the block holding the branch
    2. Strong count on a branch that has ever contained a stub never
       reached 0 because we increment the `.clone()` call for
       `BranchRef::into_raw()` didn't have a matching decrement.
    
    It's not safe to immediately deallocate blocks during
    invalidation since `branch_stub_hit()` can end up
    running with a branch pointer from an invalidated branch.
    To plug the leaks, we wait until code GC or global invalidation and
    deallocate the blocks for iseqs that are definitely not running.
    a0b0365e
    YJIT: Deallocate `struct Block` to plug memory leaks
    Alan Wu authored
    Previously we essentially never freed block even after invalidation.
    Their reference count never reached zero for a couple of reasons:
    1. `Branch::block` formed a cycle with the block holding the branch
    2. Strong count on a branch that has ever contained a stub never
       reached 0 because we increment the `.clone()` call for
       `BranchRef::into_raw()` didn't have a matching decrement.
    
    It's not safe to immediately deallocate blocks during
    invalidation since `branch_stub_hit()` can end up
    running with a branch pointer from an invalidated branch.
    To plug the leaks, we wait until code GC or global invalidation and
    deallocate the blocks for iseqs that are definitely not running.
Loading