Skip to content
  • Jean Boussier's avatar
    cb82f5f0
    Fix DescendantTracker.clear on Ruby 3.1 · cb82f5f0
    Jean Boussier authored
    Previously I assumed it was useless, however I was wrong.
    
    The method is called by the reloader to give the illusion that
    the GC is precise. Meaning a class that will be unloaded is
    immediately made invisible without waiting for it to be garbage collected.
    
    This is easy to do up to Ruby 3.0 because `DescendantTracker` keeps
    a map of all tracked classes.
    
    However on 3.1 we need to use the inverse strategy, we keep a WeakMap
    of all the classes we cleared, and we filter the return value of `descendants`
    and `subclasses`.
    
    Since `clear` is private API and is only used when reloading is enabled,
    to reduce the performance impact in production mode, we entirely remove
    this behavior when `config.cache_classes` is enabled.
    cb82f5f0
    Fix DescendantTracker.clear on Ruby 3.1
    Jean Boussier authored
    Previously I assumed it was useless, however I was wrong.
    
    The method is called by the reloader to give the illusion that
    the GC is precise. Meaning a class that will be unloaded is
    immediately made invisible without waiting for it to be garbage collected.
    
    This is easy to do up to Ruby 3.0 because `DescendantTracker` keeps
    a map of all tracked classes.
    
    However on 3.1 we need to use the inverse strategy, we keep a WeakMap
    of all the classes we cleared, and we filter the return value of `descendants`
    and `subclasses`.
    
    Since `clear` is private API and is only used when reloading is enabled,
    to reduce the performance impact in production mode, we entirely remove
    this behavior when `config.cache_classes` is enabled.
Loading