Skip to content
  • Alan Wu's avatar
    b74d6563
    Extract yjit_force_iv_index and make it work when object is frozen · b74d6563
    Alan Wu authored
    In an effort to simplify the logic YJIT generates for accessing instance
    variable, YJIT ensures that a given name-to-index mapping exists at
    compile time. In the case that the mapping doesn't exist, it was created
    by using rb_ivar_set() with Qundef on the sample object we see at
    compile time. This hack isn't fine if the sample object happens to be
    frozen, in which case YJIT would raise a FrozenError unexpectedly.
    
    To deal with this, make a new function that only reserves the mapping
    but doesn't touch the object. This is rb_obj_ensure_iv_index_mapping().
    This new function superceeds the functionality of rb_iv_index_tbl_lookup()
    so it was removed.
    
    Reported by and includes a test case from John Hawthorn <john@hawthorn.email>
    
    Fixes: GH-282
    b74d6563
    Extract yjit_force_iv_index and make it work when object is frozen
    Alan Wu authored
    In an effort to simplify the logic YJIT generates for accessing instance
    variable, YJIT ensures that a given name-to-index mapping exists at
    compile time. In the case that the mapping doesn't exist, it was created
    by using rb_ivar_set() with Qundef on the sample object we see at
    compile time. This hack isn't fine if the sample object happens to be
    frozen, in which case YJIT would raise a FrozenError unexpectedly.
    
    To deal with this, make a new function that only reserves the mapping
    but doesn't touch the object. This is rb_obj_ensure_iv_index_mapping().
    This new function superceeds the functionality of rb_iv_index_tbl_lookup()
    so it was removed.
    
    Reported by and includes a test case from John Hawthorn <john@hawthorn.email>
    
    Fixes: GH-282
Loading