zhuoerri (秦阳)

Object Shapes 浅析

zhuoerri — Sat, 03 Feb 2024 22:27:53 +0800

前言

本人水平有限，如有错误，欢迎指正与补充。

ruby 3.2 除了 YJIT，还有一些别的小优化，例如也是来自 shopify 的 Object Shapes。其作用有提高缓存命中率，加速实例变量 (和别的属性) 的读写。

Shape Tree

Object Shapes 的思路是设计一个全局的前缀树 Shape Tree, 每新增一个实例变量时，就增加一个节点。如下 foo 的形状 id 是 2, bar 的形状 id 是 4

class Foo
  def initialize
    # Currently this instance is the root shape (ID 0)
    @a = 1 # Transitions to a new shape via edge @a (ID 1)
    @b = 2 # Transitions to a new shape via edge @b (ID 2)
  end
end

class Bar
  def initialize
    # Currently this instance is the root shape (ID 0)
    @a = 1 # Transitions to shape defined earlier via edge @a (ID 1)
    @c = 1 # Transitions to a new shape via edge @c (ID 3)
    @b = 1 # Transitions to a new shape via edge @b (ID 4)
  end
end

foo = Foo.new # blue in the diagram
bar = Bar.new # red in the diagram

这样的好处是，例如根据这棵树，就可以知道 foo 的@b实例变量是在第二的位置，直接读取 foo 的第二个实例变量就能读取到@b，而不用顺着类的继承链找。

Inline Cache

这棵树的另一个好处是，可以提高缓存命中率。ruby 写入实例变量的字节码 setinstancevariable，有一个内联缓存 inline cache, 例如下图的<is:0>, <is:1>

def a
  @a = 0
  @b = 0
end
puts RubyVM::InstructionSequence.of(method(:a)).disasm

== disasm: #<ISeq:a@(irb):17 (17,0)-(20,3)> (catch: FALSE)
0000 putobject_INT2FIX_0_                                             (  18)[LiCa]
0001 setinstancevariable                    :@a, <is:0>
0004 putobject_INT2FIX_0_                                             (  19)[Li]
0005 dup
0006 setinstancevariable                    :@b, <is:1>
0009 leave                                                            (  20)[Re]
=> nil

ruby 3.2 前的实例变量的缓存逻辑是根据类，如果子类继承的话，会让缓存无效。但现在根据前缀树 Shape Tree, 则下面的 hoge 和 fuga 是相同的形状 id, initialize 方法里能让缓存命中

class Hoge
  def initialize
    # fuga初始状态，形状id为0
    @a = 0 # <is:0>缓存里，记录了上次hoge的{ 形状id为0 => 位置1 }, 命中缓存，从而得知@a在第一个的位置, 然后fuga形状id变为1
    @b = 0 # <is:1>缓存里，记录了上次hoge的{ 形状id为1 => 位置2 }, 命中缓存，从而得知@b在第二个的位置，然后fuga形状id变为2
  end
end

class Fuga < Hoge; end

hoge = Hoge.new
fuga = Fuga.new

红黑树

为了防止实例变量太多，前缀树太深，不好查找。2023 年，tenderlove 加入了红黑树，当 Shape Tree 深度达到阈值后，新建一颗对应的红黑树来加速查找

简略后源码如下：

/* https://github.com/ruby/ruby/blob/5124f9ac7513eb590c37717337c430cb93caa151/vm_insnhelper.c#L1616C1-L1641C2 */

/* 设置实例变量的字节码对应的函数 */
static inline void
vm_setinstancevariable(const rb_iseq_t *iseq, VALUE obj, ID id, VALUE val, IVC ic)
{
    shape_id_t dest_shape_id;
    attr_index_t index;
    vm_ic_atomic_shape_and_index(ic, &dest_shape_id, &index); /* 从inline cache缓存中读取形状id和实例变量位置index */

    if (UNLIKELY(UNDEF_P(vm_setivar(obj, id, val, dest_shape_id, index)))) { /* vm_setivar会检查缓存的dest_shape_id是否匹配当前对象obj的形状id */
        vm_setivar_slowpath_ivar(obj, id, val, iseq, ic); /* 如果inline cache缓存没命中，则还是顺着继承链找实例变量位置, 把位置写入新Shape Tree节点。同时写入inline cache缓存，供下次尝试匹配 */
    }
}


/* github.com/ruby/ruby/blob/5124f9ac7513eb590c37717337c430cb93caa151/shape.c#L459C1-L487C2 */

/* Shape Tree 创建子节点的函数 */
static rb_shape_t *
rb_shape_alloc_new_child(ID id, rb_shape_t * shape, enum shape_type shape_type)
{
    rb_shape_t * new_shape = rb_shape_alloc(id, shape, shape_type); /* 新建节点 */

    switch (shape_type) {
      case SHAPE_IVAR: /* 如果是用于实例变量的节点 */
        new_shape->next_iv_index = shape->next_iv_index + 1; /* 新节点的实例变量位置是父节点位置 + 1 */
        if (new_shape->next_iv_index > ANCESTOR_CACHE_THRESHOLD) {
            redblack_cache_ancestors(new_shape); /* 如果深度超过阈值，新建一个红黑树来加速查找 */
        }
        break;
      case SHAPE_FROZEN:
      case SHAPE_T_OBJECT:
        new_shape->next_iv_index = shape->next_iv_index;
        break;
      case SHAPE_OBJ_TOO_COMPLEX:
      case SHAPE_ROOT:
        rb_bug("Unreachable");
        break;
    }

    return new_shape;
}

参考资料

本文只简单讲了缓存命中率，Object Shapes 还有精简代码，有利 jit 等好处，详情见下面的帖子和视频演讲

https://bugs.ruby-lang.org/issues/18776

https://rubykaigi.org/2022/presentations/jemmaissroff.html

垃圾回收原理浅析

zhuoerri — Tue, 26 Apr 2022 12:32:28 +0800

前言

本人水平有限，如有错误，欢迎指正和补充。

本文会用自问自答的形式，用【公司裁员】打比方，结合 Ruby 3.1 源码，科普 Ruby 垃圾回收的基本原理。内容包含：Ruby 内存模型，标记回收算法，分代回收，增量回收，碎片整理，最后借助最新的 Variable Width Allocation，列举一下局部性原理。

Ruby 内存模型

Q: Ruby 对象在内存里是怎么存储管理的？

每个 Ruby 对象占用一个slot，一个slot 在 64 位的机器上占 40 字节，多个slot聚成一个 Rubypage。所有page组成了Ruby HEAP。如果 Ruby 对象太大，例如一个很长的 String，40 个字节放不下。则在总HEAP里 malloc 一块额外内存来存储。如下图，第一个slot指向了额外数据。

┌──────────────────────────────────────────────────────────────────────────────────┐
│                                                                                  │
│   HEAP  ┌────────────────────────────────────────────────────────────────────┐   │
│         │    RUBY HEAP                                                       │   │
│         │ ┌───────────────────┐ ┌───────────────────┐ ┌───────────────────┐  │   │
│         │ │ page              │ │ page              │ │ page              │  │   │
│         │ │                   │ │                   │ │                   │  │   │
│         │ │ ┌─────┐   ┌─────┐ │ │ ┌─────┐   ┌─────┐ │ │ ┌─────┐   ┌─────┐ │  │   │
│         │ │ │slot │   │slot │ │ │ │slot │   │slot │ │ │ │slot │   │slot │ │  │   │
│      ┌──┼─┼─┤     │   │     │ │ │ │     │   │     │ │ │ │     │   │     │ │  │   │
│      │  │ │ └─────┘   └─────┘ │ │ └─────┘   └─────┘ │ │ └─────┘   └─────┘ │  │   │
│      │  │ │                   │ │                   │ │                   │  │   │
│      │  │ │ ┌─────┐   ┌─────┐ │ │ ┌─────┐   ┌─────┐ │ │ ┌─────┐   ┌─────┐ │  │   │
│      │  │ │ │slot │   │slot │ │ │ │slot │   │slot │ │ │ │slot │   │slot │ │  │   │
│      │  │ │ │     │   │     │ │ │ │     │   │     │ │ │ │     │   │     │ │  │   │
│      │  │ └─┴─────┴───┴─────┴─┘ └─┴─────┴───┴─────┴─┘ └─┴─────┴───┴─────┴─┘  │   │
│      │  │                                                                    │   │
│      │  └────────────────────────────────────────────────────────────────────┘   │
│      │                                                                           │
│      │                                                                           │
│      │                                                                           │
│     ┌▼───────────────┐                                                           │
│     │ extra data     │                                                           │
│     │                │                                                           │
│     └────────────────┘                                                           │
│                                                                                  │
│                                                                                  │
└──────────────────────────────────────────────────────────────────────────────────┘

heap 和 page 的源码在 gc.c , 精简后如下

typedef struct rb_heap_struct {
    struct heap_page *free_pages;
    struct list_head pages;  /* 存放的所有pages， 指向了第一个page */
    struct heap_page *sweeping_page; /* 用来迭代每个pages的临时指针 */
    /* 省略 */
    size_t total_pages;      /* 总page数 */
    size_t total_slots;      /* 总slot数 */
} rb_heap_t;

struct heap_page {
    short total_slots;  /* page内总slot数 */
    short free_slots;  /* page内空闲的slot数 */
    /* 省略 */
    struct heap_page *free_next;  /* 下一个可用的page */
    RVALUE *start; /* page内第一个slot地址 */
    RVALUE *freelist; /* page内空闲的slot列表 */
    /* 省略 */
}

Q: 还是不懂，能打个比方吗？

可以用【公司裁员】来比喻 Ruby 垃圾回收。page可以看作公司【办公室】,slot 看作【工位】, Ruby对象看作【员工】，每个【员工】占一个【工位】。如果一个【工位】不够放私人物品，则在外部【储物柜】(总HEAP) 存放额外数据

Q: 如果【工位】(`slot`) 不够了？

裁掉对公司无用的【员工】(Ruby对象), 空出【工位】(slot) 给【新员工】(新Ruby对象)

Q: 如果裁员后【工位】(`slot`) 还是不够？

租更多的【办公室】(向操作系统要更多的 Rubypage)

Q: 什么时候退租【办公室】(`page`),还内存给操作系统？

空闲【工位】(slot) 的空置率最多 65%。如果裁员完空余【工位】(slot) 超过 65% 的，则超出 65% 的部分是可以退租的额度。Ruby 会在退租额度内，选择完全空置的【办公室】(page) 退租。Ruby 管这种完全空置的page叫tomb page, 管还有 Ruby 对象的page叫eden page.

是否还内存给操作系统的源码也在 gc.c, 精简后如下

/* 在确定了裁员名单后，正式裁员前。会调这个gc_marks_finish函数 */
static int
gc_marks_finish(rb_objspace_t *objspace)
{
  /* 省略 */

  size_t total_slots = heap_allocatable_pages * HEAP_PAGE_OBJ_LIMIT + heap->total_slots;
  size_t sweep_slots = total_slots - objspace->marked_slots; /* 总slot数减去保留的slot数，就是当前空闲的slot数 */
  size_t max_free_slots = (size_t)(total_slots * gc_params.heap_free_slots_max_ratio); /* heap_free_slots_max_ratio默认0.65， 总slot数乘以 0.65 就是空闲slot数的上限 */

  /* 省略 */

  /* 【裁员的slot数】 减去 【空置slot数上限】 , 再除以【每个page内单位slot数】这个单位。最后算出的heap_pages_freeable_pages 就是可以还给操作系统的page数量 */
  if (sweep_slots > max_free_slots) {
      heap_pages_freeable_pages = (sweep_slots - max_free_slots) / HEAP_PAGE_OBJ_LIMIT;
  }
  else {
      heap_pages_freeable_pages = 0;
  }
}

/* 裁员完毕后，会调这个 heap_pages_free_unused_pages函数 */
static void
heap_pages_free_unused_pages(rb_objspace_t *objspace)
{
  /* 省略 */

  /* 如果有退租slot数的额度*/
  if (has_pages_in_tomb_heap) {
        for (i = j = 1; j < heap_allocated_pages; i++) {
            struct heap_page *page = heap_pages_sorted[i];

            /* 如果还有退租slot数的额度，并且当前page是完全空置, 则退还page给操作系统 */
            if (page->flags.in_tomb && page->free_slots == page->total_slots) {
                heap_unlink_page(objspace, heap_tomb, page);
                heap_page_free(objspace, page);
            }

            /* 省略 */
        }
   }
}

Q: 怎么判断哪些【员工】(`Ruby对象`) 是无用的，需要被裁？

用标记回收算法，具体见下一节

标记回收算法

Q: 标记回收算法的流程是怎样的？

还是以公司裁员为例子，分两个阶段：

第一个阶段 Mark，标记有用。HR 从最顶层的总裁问起，觉得谁有用？总裁觉得副总裁 A 和副总裁 B 有用。HR 把副总裁 A 和副总裁 B 标记为有用。然后 HR 再去问副总裁 A 和副总裁 B，觉得谁有用？副总裁们觉得经理 C 和经理 D 有用........。以此类推，递归地标记有用和问下去。最后没有被问到的人，没有被标记有用的人，就可以准备裁了
第二个阶段 Sweep，回收工位。找到所有未标记有用的人，裁掉，让出【工位】(slot)。

标记回收的源码也在 gc.c, 精简后如下

/* 标记obj对象有用 */
static void
gc_mark_ptr(rb_objspace_t *objspace, VALUE obj)
{
  /* 省略 */

  if (!gc_mark_set(objspace, obj)) return; /* 如果已经标记过，则return；否则标记成功，接着执行 */

  /* 省略 */

  gc_grey(objspace, obj); /* 把obj推入栈中，方便之后问它引用了哪些子对象, 觉得哪些子对象有用 */

  /* 省略 */
}

/* 推入栈中 */
static void
gc_grey(rb_objspace_t *objspace, VALUE obj)
{
  /* 省略 */

  push_mark_stack(&objspace->mark_stack, obj);
}

/* 之后从栈中取出对象 */
static inline int
gc_mark_stacked_objects(rb_objspace_t *objspace, int incremental, size_t count)
{
  /* 省略 */

  while (pop_mark_stack(mstack, &obj)) {
     /* 省略 */

     /* 从栈中取出obj，再递归的标记obj引用了的子对象。gc_mark_children之后又会递归调用上面的 gc_mark_ptr 函数标记子对象*/
     gc_mark_children(objspace, obj);
  }

  /* 省略 */
}


/* 标记完后，对每个page调 gc_page_sweep 函数进行回收检查 */
static inline void
gc_sweep_page(rb_objspace_t *objspace, rb_size_pool_t *size_pool, rb_heap_t *heap, struct gc_sweep_context *ctx)
{
  /* 省略 */

  /* page内第一个slot的地址，存在p里 */
  p = sweep_page->start;

  /* page内用一个位图数组mark_bits来标记每个slot是否有用 */
  bits = sweep_page->mark_bits;

  /* 循环检查每个slot对应的位图 */
  for (i=0; i < HEAP_PAGE_BITMAP_LIMIT; i++) {
    bitset = ~bits[i];  /* 把位图取反，就是没有被标记的slot */
    if (bitset) {

        /* 如果取反的位图数组有未标记的slot，调gc_sweep_plane回收 slot, 函数定义见下方 */
        gc_sweep_plane(objspace, heap, (uintptr_t)p, bitset, ctx);
    }
    p += BITS_BITLENGTH;
  }

  /* 省略 */
}

static inline void
gc_sweep_plane(rb_objspace_t *objspace, rb_heap_t *heap, uintptr_t p, bits_t bitset, struct gc_sweep_context *ctx)
{
   /* 省略 */

   do {
        VALUE vp = (VALUE)p;

        /* 取反位图的右边最低位是1，说能原位图右边最低位是0，说明该位对应的slot没被标记，可以被回收 */
        if (bitset & 1) {
          /* 省略 */

          obj_free(objspace, vp) /* 删除slot上的变量，清空slot */

          /* 省略 */
        }

        /* 循环找下一个slot，取反位图bitset右移到下一位 */
        p += slot_size;
        bitset >>= slot_bits;
  }while (bitset);
}

Q: 每次裁员要从头问一遍所有人，有什么办法优化吗？

用 Ruby 2.1 新增的分代回收算法，具体见下一节

分代回收

Q: 分代回收算法的流程是怎样的？

还是以公司裁员打比方。分为【大裁员】(Major/Full) 和【小裁员】(Minor)。

【大裁员】(Major/Full) 还是和之前一样，问一遍所有人。

【小裁员】(Minor) 会默认一些【员工】(Ruby对象) 有用，跳过对这些【员工】(Ruby对象) 的标记和询问。

Q: 哪些【员工】(`Ruby对象`) 会默认有用？

被标记过 3 次的，即躲过三次裁员的【老员工】(Ruby 管这种对象叫old object) 默认有用。同时，【老员工】(old object) 觉得有用的子员工，也自动变为【老员工】, 形成了一个老员工帮。

例如，某个员工之前躲过了两次裁员。当第三次裁员时，HR 询问该员工觉得谁有用时，发现算上目前这次，该员工已经躲过三次裁员了，就把该员工标记为【老员工】(old object)。该员工觉得员工 A 和员工 B 有用，则 HR 把员工 A 和员工 B 也标记为【老员工】(old object)。以此类推，员工 A 和员工 B 又觉得员工 C 和员工 D 有用，则 HR 把员工 C 和员工 D 也标记为【老员工】.....

当第四次【小裁员】(minor) 时，HR 默认这帮老员工有用，跳过对这些老员工的标记和询问

Q: 上面的例子，如果在第三次裁员后，第四次裁员前，新招了一个新员工 E，某个【老员工】(`old object`) 觉得新员工 E 有用。但 HR 跳过了老员工的询问，不知道员工 E 有用，第四次裁员时误裁掉员工 E。怎么办？

【老员工】(old object) 主动给 HR 说，下次裁员时，强制询问我谁有用。HR 给【老员工】(old object) 标记下次【强制询问】的标签。等下次裁员结束，保住了员工 E 后，就可以清除【强制询问】的标签。

Ruby 里这种主动标记强制询问的方法叫 write barrier。Ruby 管这种主动标记强制询问的对象叫 write barrier protected object

Q: 所有的员工都会这么主动帮新员工吗？

很可惜，不会，因为要兼容第三方 c 扩展库。Ruby 给新函数加上了write barrier 行为，但第三方 c 扩展使用的可能是不带write barrier的老函数

Q: 那怎么办？

HR 把这些不主动的员工标记为【老油条】（Ruby 里叫 write barrier unprotected object或者shady）。就算【老油条】混成了【老员工】，HR 每次裁员时，还是要强制标记和询问【老油条】(write barrier unprotected object/shady)

分代回收的源码还是在 gc.c , 精简后如下

/* 标记开始函数 */
static void
gc_marks_start(rb_objspace_t *objspace, int full_mark)
{
  /* 是否大裁员 Major/Full */
  if (full_mark) {
    /* 大裁员 */
    objspace->flags.during_minor_gc = FALSE;


    for (int i = 0; i < SIZE_POOL_COUNT; i++) {
        /* 清空之前标记的【是否有用】【是否强制询问】【是否老员工】等标志 */
        rgengc_mark_and_rememberset_clear(objspace, SIZE_POOL_EDEN_HEAP(&size_pools[i]));
    }
  }
  else {
    /* 小裁员 */
    objspace->flags.during_minor_gc = TRUE;

    for (int i = 0; i < SIZE_POOL_COUNT; i++) {

       /* 先把需要【强制询问】或【老油条】的对象标记询问 */
       rgengc_rememberset_mark(objspace, SIZE_POOL_EDEN_HEAP(&size_pools[i]));
    }
  }

  /* 从顶层对象开始标记询问，gc_mark_roots会调用上一节源码里的 gc_mark_ptr */
  gc_mark_roots(objspace, NULL);
}

/* 清空各种标记位图数组 */
static void
rgengc_mark_and_rememberset_clear(rb_objspace_t *objspace, rb_heap_t *heap)
{
    struct heap_page *page = 0;

    /* mark_bits是【是否有用】的位图数组, uncollectible_bits是【是否老员工/old object】的位图数组, marking_bits是时是否【强制询问】的位图数组; pinned_bits先忽略，讲到碎片整理一节时再说 */
    list_for_each(&heap->pages, page, page_node) {
    memset(&page->mark_bits[0],       0, HEAP_PAGE_BITMAP_SIZE);
    memset(&page->uncollectible_bits[0], 0, HEAP_PAGE_BITMAP_SIZE);
        memset(&page->marking_bits[0],    0, HEAP_PAGE_BITMAP_SIZE);
        memset(&page->pinned_bits[0],     0, HEAP_PAGE_BITMAP_SIZE);

        /* 省略 */
    }
}

/* 标记【强制询问】或【老油条】对象 */
static void
rgengc_rememberset_mark(rb_objspace_t *objspace, rb_heap_t *heap)
{

        /* 省略 */

        /循环检查每个page/
        list_for_each(&heap->pages, page, page_node) { 
                if (page->flags.has_remembered_objects | page->flags.has_uncollectible_shady_objects) { 
                        RVALUE *p = page->start;

                        /* marking_bits 是【强制询问】的位图数组，uncollectible_bits是【老员工】的位图数组，wb_unprotected_bits 是【老油条】的位图数组 */
                        bits_t *marking_bits = page->marking_bits;
                        bits_t *uncollectible_bits = page->uncollectible_bits;
                        bits_t *wb_unprotected_bits = page->wb_unprotected_bits;

                        for (j=0; j<HEAP_PAGE_BITMAP_LIMIT; j++) { 
                                /* bits代表(【强制询问】或者（【老员工】并且【老油条】）) */
                                bits[j] = marking_bits[j] | (uncollectible_bits[j] & wb_unprotected_bits[j]);

                                /* 清空【强制询问】位图数组 */
                                marking_bits[j] = 0;
                        } 

                        /* 省略 */


                        for (j=1; j < HEAP_PAGE_BITMAP_LIMIT; j++) { 
                                bitset = bits[j];
                                /* 检查每个bits位图数组 */
                                rgengc_rememberset_mark_plane(objspace, (uintptr_t)p, bitset);
                                p += BITS_BITLENGTH;
                        } 
                } 
        } 
}

/* 询问有【强制询问】或【老油条】标签的对象 */
static inline void
rgengc_rememberset_mark_plane(rb_objspace_t *objspace, uintptr_t p, bits_t bitset)
{
    if (bitset) {
        do {
            if (bitset & 1) {
                VALUE obj = (VALUE)p;


                /* 标记询问有用的子对象，gc_mark_children 在上一节的源码里也出现过 */
                gc_mark_children(objspace, obj);
            }
            p += sizeof(RVALUE);
            bitset >>= 1;
        } while (bitset);
    }
}

/* 标记obj对象有用 */
static void
gc_mark_ptr(rb_objspace_t *objspace, VALUE obj)
{
  /* 省略 */

  /* 检查是obj的父标对象是谁，即是谁觉得obj有用 */
  rgengc_check_relation(objspace, obj);

  if (!gc_mark_set(objspace, obj)) return; 

  /* 省略 */

  gc_grey(objspace, obj); 

  /* 省略 */
}

/* 检查obj的父标对象是谁，是谁觉得obj有用 */
static void
rgengc_check_relation(rb_objspace_t *objspace, VALUE obj)
{       
        const VALUE old_parent = objspace->rgengc.parent_object;

        /* 如果父标记对象是【老员工】old object */
        if (old_parent) {

                /* 省略 */

                /* 把当前对象obj也标记为【老员工】old object */
                RVALUE_AGE_SET_CANDIDATE(objspace, obj);
        }

        /* 省略 */
} 

/* 标记回收结束时，对page调用gc_setup_mark_bits函数 */
static void
gc_setup_mark_bits(struct heap_page *page)
{
    /* copy oldgen bitmap to mark bitmap */
    /* 把【老员工】uncollectible_bits位图数组复制给【是否有用】mark_bits位图数组，即老员工 old object默认有用 */
    memcpy(&page->mark_bits[0], &page->uncollectible_bits[0], HEAP_PAGE_BITMAP_SIZE);
}

/* 变量a引用了变量b，觉得变量b有用时，触发writebarrier, 把变量a标记为【强制询问】 */
void
rb_gc_writebarrier(VALUE a, VALUE b)
{
    /* 省略 */

    if (!RVALUE_OLD_P(a) || RVALUE_OLD_P(b)) {
        // do nothing
    }
    else {
        /* 如果a是【老员工】(old object)，b不是【老员工】(old object), 则把a标记为【强制询问】 */
        gc_writebarrier_generational(a, b, objspace);
    }

    /* 省略 */
}


/* 把变量a标记为【强制询问】 */
static void
gc_writebarrier_generational(VALUE a, VALUE b, rb_objspace_t *objspace)
{
  /* 省略 */

  rgengc_remember(objspace, a);

  /* 省略 */
}

/* 把obj标记为【强制询问】 */
static int
rgengc_remember(rb_objspace_t *objspace, VALUE obj)
{
  /* 省略 */

  return rgengc_remembersetbits_set(objspace, obj);
}

/* 把obj标记为【强制询问】 */
static int
rgengc_remembersetbits_set(rb_objspace_t *objspace, VALUE obj)
{
    struct heap_page *page = GET_HEAP_PAGE(obj);
    bits_t *bits = &page->marking_bits[0]; /* 【强制询问】的位图数组是page内的 marking_bits */

   /* 省略 */

   page->flags.has_remembered_objects = TRUE;
   MARK_IN_BITMAP(bits, obj); /* 把obj对应的marking_bits位置标为1 */
   return TRUE;
}

Q: 【小裁员】(`minor`) 跳过【老员工】(`old object`) 减少了标记的时间。但【大裁员】(`major/full`) 依然要问一遍所有人，有什么办法优化【大裁员】(`major/full`) 吗？

用 Ruby 2.2 新加的增量回收算法，具体见下一节

增量回收

Q: 增量回收算法是怎么优化【大裁员】(`major/full`) 流程的？

【大裁员】(major/full) 需要问一遍所有人，这个客观事实是改不了的。增量回收算法的优化思路是：通过增量标记询问，尽量减少对员工们正常干活的阻塞。

在 Ruby 2.2 增量回收算法出现前。【大裁员】(major/full) 时，员工们都必须停下手头的工作，等裁员结果出来，才能继续工作。

Ruby 2.2 增量回收算法出来后。除了原先【已标记】(Ruby 叫black object) 和【未标记】(Ruby 叫white object) 这两种状态，HR 新增了一种【询问中】(Ruby 叫grey object) 状态。

例如，第一天 HR 把总裁标记为【询问中】(grey object)，总裁觉得副总裁 A 和副总裁 B 有用。HR 把副总裁 A 和副总裁 B 标记为【询问中】，把总裁标记为【已标记】(black object)。就结束了第一天的标记，员工可以接着干活。第二天，HR 在询问副总裁 A 和副总裁 B。副总裁们觉得经理 C 和经理 D 有用，HR 把经理 C 和经理 D 标记为【询问中】(grey object), 把副总裁们标记为【已标记】(black object)。结束了第二天的标记，员工可以接着干活。以此循环递归，每天增量的询问一些【询问中】的员工，直到没有【询问中】(grey object) 的员工。只剩【已标记】和【未标记】的员工。

Q: 和分代回收时同样的问题：如果某个员工 A 被标记为【已标记】(`black object`), 然后新招了一个员工 B，员工 A 觉得员工 B 有用。但因为 HR 不会再询问员工 A 了，不知道员工 B 有用，导致员工 B 被误裁，怎么办？

跟分代回收类似的解决方案，writebarrier。员工 A 主动把跟 HR 说把员工 B 从【未标记】(white object) 改为【询问中】(grey object)。实际上分代回收的【强制询问】和增量回收的【询问中】用的是同一个标记，同一个位图数组 marking_bits，因为两者的作用一致，都是让 HR 下次询问自己一次。

Q: 所有的员工都会主动帮新员工吗？

很可惜，不会，原因和分代回收时一样，为了兼容第三方 c 扩展库。必须用别的办法对付【老油条】(writebarrier unprotected object)

Q：那怎么办？

HR 在【大裁员】(major/full) 最终标记结束前，会最后再问一遍所有的【老油条】(writebarrier unprotected object)，以防漏掉了哪个有用的员工。

增量回收的源码还是在 gc.c

/* 标记了有用 mark_bits, 没标记强询问 marking_bits 的就是black object*/
static inline int
RVALUE_BLACK_P(VALUE obj)
{
    return RVALUE_MARKED(obj) && !RVALUE_MARKING(obj);
}

#if 0
/* 标记了有用 mark_bits, 同时标记了下次强制询问 marking_bits的就是grey object */
static inline int
RVALUE_GREY_P(VALUE obj)
{
    return RVALUE_MARKED(obj) && RVALUE_MARKING(obj);
}
#endif

/* 还没被标记有用mark_bits的就是white object */
static inline int
RVALUE_WHITE_P(VALUE obj)
{
    return RVALUE_MARKED(obj) == FALSE;
}

/* 增量回收中，a觉得b有用的writebarrier函数 */
static void
gc_writebarrier_incremental(VALUE a, VALUE b, rb_objspace_t *objspace)
{
    gc_report(2, objspace, "gc_writebarrier_incremental: [LG] %p -> %s\n", (void *)a, obj_info(b));

    if (RVALUE_BLACK_P(a)) {
        if (RVALUE_WHITE_P(b)) {
            if (!RVALUE_WB_UNPROTECTED(a)) {
                /* 变量a是black，变量b是white时，把变量b标记为grey */
                gc_report(2, objspace, "gc_writebarrier_incremental: [IN] %p -> %s\n", (void *)a, obj_info(b));
                gc_mark_from(objspace, b, a);
            }
        }
        else if (RVALUE_OLD_P(a) && !RVALUE_OLD_P(b)) {
            if (!RVALUE_WB_UNPROTECTED(b)) {
                /* 变量a是老对象，变量b是新对象时，把变量b标记为老对象 */
                gc_report(1, objspace, "gc_writebarrier_incremental: [GN] %p -> %s\n", (void *)a, obj_info(b));
                RVALUE_AGE_SET_OLD(objspace, b);

                if (RVALUE_BLACK_P(b)) {
                    /* 如果变量b是black时，改为grey，下次强制询问 */
                    gc_grey(objspace, b);
                }
            }
            else {
                gc_report(1, objspace, "gc_writebarrier_incremental: [LL] %p -> %s\n", (void *)a, obj_info(b));
                /* 变量b是【老油条】writebarrier unprotected, 标记b为【老员工】old object */
                gc_remember_unprotected(objspace, b);
            }
        }

        /* 省略 */
    }
}

/* 标记结束前调用的函数 */
static int
gc_marks_finish(rb_objspace_t *objspace)
{
  #if GC_ENABLE_INCREMENTAL_MARK
  /* 省略 */

  /* 增量标记结束前，再询问一遍【老油条】writebarrier unprotected object, 以防漏掉有用变量 */
  /* gc_marks_wb_unprotected_objects 函数会再询问一遍所有writebarrier unprotected object */
  for (int i = 0; i < SIZE_POOL_COUNT; i++) {
    gc_marks_wb_unprotected_objects(objspace, SIZE_POOL_EDEN_HEAP(&size_pools[i]));
  }
  #endif
}

Q: 所以一个【员工】(`Ruby对象`) 总共有哪些标记？

是否有用 (mark_bits), 是否老员工 (uncollectible_bits), 是否老油条 (wb_unprotected_bits), 是否下次强制询问 (marking_bits), 是否钉子户 (pinned_bits)

Q: 裁员完后，不换一下工位，让员工间坐得更近，空出更多的【办公室】(`page`) 吗？

可以，Ruby 2.7 加了碎片整理算法，详情见下一节

碎片整理

Q: 碎片整理算法的流程是怎样的？

以公司裁员打比方，必须先进行一次【大裁员】(major/full) 后，再执行如下两个阶段：

第一阶段，转移工位。两个 HR，一个负责在左边，从左往右找空出的【工位】(slot), 另一个负责在右边，从右往左找【员工】(Ruby对象), 各自找到合适的【工位】(slot) 和【员工】(Ruby对象) 后，把员工转移到新工位，并在原工位上留下新工位的字条。以此循环，直到找不到合适的工位或员工，两个 HR 碰到了一起。
第二阶段，更新引用。通知所有员工，根据原工位留的字条，记一下对应员工的新工位。

具体例子见下图

6个工位，4个员工，A和B记得C和D在5和6号工位
                     ┌ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─        
                        Before Compaction   │       
                     └ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─        
               ┌─────┬─────┬─────┬─────┬─────┬─────┐
 Slot Index    │  1  │  2  │  3  │  4  │  5  │  6  │
               ├─────┼─────┼─────┼─────┼─────┼─────┤
Slot Contents  │  A  │  B  │Empty│Empty│  C  │  D  │
               │     │     │     │     │     │     │
               └─────┴─────┴─────┴─────┴─────┴─────┘
                  │     │                 ▲     ▲   
                  │     │                 │     │   
                  └─────┼─────────────────┘     │   
                        └───────────────────────┘

第一阶段，C和D转移工位到3和4后，在原工位留下字条
                     ┌ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─        
                         After Compaction   │       
                     └ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─        
               ┌─────┬─────┬─────┬─────┬─────┬─────┐
 Slot Index    │  1  │  2  │  3  │  4  │  5  │  6  │
               ├─────┼─────┼─────┼─────┼─────┼─────┤
Slot Contents  │  A  │  B  │  D  │  C  │MOVED│MOVED│
               │     │     │     │     │TO 4 │TO 3 │
               └─────┴─────┴─────┴─────┴─────┴─────┘
                  │     │                 ▲     ▲   
                  │     │                 │     │   
                  └─────┼─────────────────┘     │   
                        └───────────────────────┘

第二阶段，员工A和B根据字条，更新一下记的员工C和D的工位位置
                     ┌ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─        
                        After Ref Updates   │       
                     └ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─        
               ┌─────┬─────┬─────┬─────┬─────┬─────┐
 Slot Index    │  1  │  2  │  3  │  4  │  5  │  6  │
               ├─────┼─────┼─────┼─────┼─────┼─────┤
Slot Contents  │  A  │  B  │  D  │  C  │MOVED│MOVED│
               │     │     │     │     │TO 4 │TO 3 │
               └─────┴─────┴─────┴─────┴─────┴─────┘
                  │     │     ▲     ▲               
                  │     │     │     │               
                  └─────┼─────┼─────┘               
                        └─────┘

Q: 所有员工都会乖乖换工位吗？

很可惜，不会，原因和分代回收一样，为了兼容第三方 c 扩展库。碎片整理时会跳过这些【钉子户】(Ruby 内叫pinned object)

由于原理很简单，更多的难点是在为了升级第三方 c 扩展库，而提供的rb_gc_location, rb_data_type_struct中的dcompact回调函数指针等，本节省略源码解析

Q: 碎片整理除了空出更多的【办公室】(`page`), 还有别的好处吗？

有，根据局部性原理，能优化读取速度。

局部性原理

Q: 什么是局部性原理？

cpu 读取内存数据时，如果是读取相邻的顺序数据，更有机会被 L1，L2，L3 缓存命中，提高性能。

Q: 除了碎片整理，Ruby 垃圾回收中还有哪些优化用到了局部性原理吗？

Ruby 3.1 新加了 Variable Width Allocation, 但跟 jit 一样默认是关闭状态的实验特性。

原先一个【工位】(slot) 只有 40 字节，额外数据需要存储在外部 heap。Variable Width Allocation 的原理是，把【工位】(slot) 扩大到 40 字节，80 字节，160 字节，320 字节四种。虽然可能造成一定的空间浪费，但根据局部性原理，提高了性能。

详情见 Variable Width Allocation 的 redmine

https://bugs.ruby-lang.org/issues/18045

https://bugs.ruby-lang.org/issues/18239

Q: 除了垃圾回收，Ruby 中还有哪些优化用到了局部性原理吗？

Ruby 2.4 中用局部性原理优化了 Hash 的实现，详情见下面文章中 Hash changes 的科普 https://blog.heroku.com/ruby-2-4-features-hashes-integers-rounding

YJIT 打算用 Rust 重写

zhuoerri — Fri, 18 Feb 2022 13:49:11 +0800

https://bugs.ruby-lang.org/issues/18481

以后 ~~安装 ruby~~ 从源码编译安装 ruby 时，可能需要先安装 rustc, cargo 才能开启 YJIT 了

Ruby YJIT 原理浅析

zhuoerri — Tue, 18 Jan 2022 13:13:51 +0800

前言

本人水平有限，如有错误，欢迎指正与补充。

YJIT 是 shopify 公司开发的 jit, 已于去年合并到了 ruby 源码。本文会结合源码从字节码，YJIT，到背后的 Lazy Basic Block Versioning (LBBV) 概念进行浅析，最后个人感叹一下软件缓存。

字节码

Ruby 自 1.9 版本开始，代码执行过程变为 Ruby源码 -> 字节码 -> YARV虚拟机 。可用 RubyVM::InstructionSequence.disasm 查看生成的字节码，如下代码

def get(obj, idx)
  return obj[idx]
end
puts RubyVM::InstructionSequence.disasm(method(:get))

[ 2] obj@0<Arg> [ 1] idx@1<Arg>
0000 getlocal_WC_0                          obj@0                     (   7)[LiCa]
0002 getlocal_WC_0                          idx@1
0004 opt_aref                               <calldata!mid:[], argc:1, ARGS_SIMPLE>
0006 leave                                                            (   8)[Re]

如上，总共生成了 4 个字节码：第一个 getlocal_WC_0 获取变量 obj , 第二个getlocal_WC_0获取变量 idx, 第三个opt_aref代表源码里的 [], 第四个leave代表 return。ruby 定义的所有字节码及对应的 c 源码，可在 insns.def里查看，最后一个字节码是关于 42 的梗

本文主要讲 YJIT，对于 YARV 虚拟机感兴趣的同学推荐ruby-under-a-microscope(Ruby 原理剖析)

JIT

YARV 虚拟机执行字节码前，会尝试先用 JIT 来执行，c 源码在vm.c, 精简后如下

VALUE
vm_exec(rb_execution_context_t *ec, bool mjit_enable_p)
{
        /* 省略 */

        if (!mjit_enable_p || (result = mjit_exec(ec)) == Qundef) { /* 没有启动jit，或者jit的执行结果mjit_exec是不成功 Qundef， 则回到虚拟机正常执行 */
            result = vm_exec_core(ec, initial);
        }
        goto vm_loop_start;

        /* 省略 */
}

mjit_exec 会尝试构造一个函数指针，然后执行该函数。源码在 mjit.h, 精简后如下

static inline VALUE
mjit_exec(rb_execution_context_t *ec)
{
  /* 省略 */

  yjit_enabled = rb_yjit_enabled_p();
  if (yjit_enabled && !mjit_call_p && body->total_calls == rb_yjit_call_threshold())  { /* 如果启动了yjit 并且这段字节码的总执行次数达到了yjit的限制，默认10次，则yjit尝试编译字节码 */
        if (!rb_yjit_compile_iseq(iseq, ec)) {  /* YJIT编译字节码，如果编译失败，返回Qundef */
            return Qundef;
        }
  }

  /* 省略 */

  mjit_func_t func = body->jit_func; /* 如果YJIT编译成功，获取函数指针 */
  // ec -> RDI         按照惯例，ec会存入RDI寄存器, 原由见下方的 yjit_entry_prologue 函数
  // cfp -> RSI        按照惯例, cfp会存入RSI寄存器, 原由见下方的 yjit_entry_prologue 函数
  return func(ec, ec->cfp); /* 执行函数指针对应的函数 */
}

剩下的工作，就是 YJIT 的 rb_yjit_compile_iseq 函数如何编译字节码，并返回一个函数指针？

YJIT

YJIT 为大部分字节码，注册了一个处理函数，例如一开始的 opt_aref 字节码，在 yjit_codegen.c 中注册了 gen_opt_aref 处理函数，精简如下

void
yjit_init_codegen(void)
{
   /* 省略 */
   yjit_reg_op(BIN(opt_neq), gen_opt_neq);
   yjit_reg_op(BIN(opt_aref), gen_opt_aref);
   yjit_reg_op(BIN(opt_aset), gen_opt_aset);
   /* 省略 */
}

gen_opt_aref 处理函数，用手动编写汇编机器码的方式，在内存中写入 X86 汇编代码，精简如下

static codegen_status_t
gen_opt_aref(jitstate_t *jit, ctx_t *ctx, codeblock_t *cb)
{
  /* 省略 */

  if (CLASS_OF(comptime_recv) == rb_cArray && RB_FIXNUM_P(comptime_idx)) { /* 如果参数类型分别是 Array和Fixnum */
    mov(cb, RDI, recv_opnd);  /* 生成mov 汇编语句 */
    sar(cb, REG1, imm_opnd(1)); /* 生成sar汇编语句 */
    mov(cb, RSI, REG1); /* 生成 mov 汇编语句 */
    call_ptr(cb, REG0, (void *)rb_ary_entry_internal); /* 生成call汇编语句，调用实际的rb_ary_entry_internal函数 */

    x86opnd_t stack_ret = ctx_stack_push(ctx, TYPE_UNKNOWN);
    mov(cb, stack_ret, RAX); /* 生成mov汇编语句，把 rb_ary_entry_internal 的返回值(RAX寄存器的值)存入YARV虚拟机的栈顶 */

    jit_jump_to_next_insn(jit, ctx); /* 生成jmp汇编语句，继续执行后续的字节码生成的汇编语句 */
    return YJIT_END_BLOCK;
  }
  else if (CLASS_OF(comptime_recv) == rb_cHash) { 
    /* 参数类型是Hash， 生成对应汇编语句，省略 */
  }
  else {
    /* 参数类型是Proc, lambda 等, 生成对应汇编语句，省略 */
  }  

  /* 省略 */
}

除了上面的 mov, sar, call_ptr, 其他完整的汇编机器码写入内存的函数，在yjit_asm.c。

可想而之，YJIT 的 rb_yjit_compile_iseq 就是把字节码对应的汇编机器码写入内存，并把该内存地址作为函数指针返回了。完整代码入口见yjit_iface.c, 精简如下

bool
rb_yjit_compile_iseq(const rb_iseq_t *iseq, rb_execution_context_t *ec)
{
    /* 省略 */
    bool success = true;
    uint8_t *code_ptr = gen_entry_point(iseq, 0, ec); /* 获取汇编代码的内存地址, 详情见下方函数 */

    /* 省略 */

    if (code_ptr) {
        iseq->body->jit_func = (yjit_func_t)code_ptr; /* 把汇编代码的内存地址存入函数指针 */
    }
    return success;
}

static uint8_t *
gen_entry_point(const rb_iseq_t *iseq, uint32_t insn_idx, rb_execution_context_t *ec)
{
  /* 省略 */

  uint8_t *code_ptr = yjit_entry_prologue(cb, iseq); /* 生成初始汇编代码，把相关寄存器存入栈中, 返回初始内存地址, 详情见下方函数 */

  /* 省略 */

  block_t *block = gen_block_version(blockid, &DEFAULT_CTX, ec); /* 根据字节码，生成后续的汇编代码。目前先省略,后续谈到LBBV的branch_stub_hit函数时，会再深入 */
  return code_ptr;
}

static uint8_t *
yjit_entry_prologue(codeblock_t *cb, const rb_iseq_t *iseq)
{
    /* 省略 */

    uint8_t *code_ptr = cb_get_ptr(cb, cb->write_pos); /* 获取初始内存地址 */
    ADD_COMMENT(cb, "yjit entry");

    push(cb, REG_CFP); /* 在内存中写入 push 汇编代码 */
    push(cb, REG_EC); /* 在内存中写入 push 汇编代码 */
    push(cb, REG_SP); /* 在内存中写入 push 汇编代码 */

    mov(cb, REG_EC, C_ARG_REGS[0]); /* mov汇编代码, 从C_ARG_REGS[0]即RDI寄存器, 获取传入的参数EC, 存入REG_EC寄存器 */
    mov(cb, REG_CFP, C_ARG_REGS[1]); /* mov汇编代码, 从 C_ARG_REGS[0]即RSI寄存器, 获取传入的参数CFP, 存入REG_CFP寄存器 */

    /* 把 cfp->sp 地址, 存入 REG_SP寄存器 */
    mov(cb, REG_SP, member_opnd(REG_CFP, rb_control_frame_t, sp));

    /* 把return相关的leave_exit_code汇编代码，存入 cfp->jit_return 函数指针 */
    mov(cb, REG0, const_ptr_opnd(leave_exit_code));
    mov(cb, member_opnd(REG_CFP, rb_control_frame_t, jit_return), REG0);

    return code_ptr; /* 返回初始内存地址 */
}

Lazy Basic Block Versioning (LBBV)

如果只是把字节码手动转成汇编代码执行，那和直接让 YARV 虚拟机执行字节码没什么区别;因此 YJIT 额外用了名为 Lazy Basic Block Versioning(LBBV) 的优化方法，详情见 YJIT 作者发表的LBBV 论文

Lazy

Lazy Basic Block Versioning 中的 Lazy 代表懒生成，类似 ActiveRecord 中的 where 懒加载，只有在调用 to_a, each 等语句时才会真正触发 sql。YJIT 一开始生成的是一段 stub(空壳汇编代码)，只有空壳代码被执行时，才继续生成真正的汇编代码。用 ruby 举例的话，类似如下代码


def time_consuming_operation
  if respond_to?(:real_time_consuming_operation)
    send(:real_time_consuming_operation)
  else
    stub
  end
end

def stub
  define_method(:real_time_consuming_operation) do
    # time consuming operations
  end
  time_consuming_operation
end

if false
  time_consuming_operation
else
  # other operation
end

如上，如果执行时 if false, time_consuming_operation 暂时不被真正执行，则暂时不会生成实际的 real_time_consuming_operation 方法。YJIT 用懒生成的方式节省了汇编代码大小，省略了暂时不需要真正执行的汇编代码。还是以opt_aref 字节码对应的处理函数gen_opt_aref 源码为例子，精简后如下

static codegen_status_t
gen_opt_aref(jitstate_t *jit, ctx_t *ctx, codeblock_t *cb)
{
  /* 省略 */

  /* 如果是初次编译字节码，而不是真的执行到了对应的汇编代码。则调用defer_compilation 生成空壳汇编代码 */
  if (!jit_at_current_insn(jit)) {
      defer_compilation(jit, ctx); /* 生成空壳汇编代码，详情见下方函数 */
      return YJIT_END_BLOCK;
  }
  /* 否则执行下面的语句，生成实际的汇编代码 */

  if (CLASS_OF(comptime_recv) == rb_cArray && RB_FIXNUM_P(comptime_idx)) { /* 如果参数类型分别是 Array和Fixnum */
    mov(cb, RDI, recv_opnd);  /* 生成mov 汇编语句 */
    sar(cb, REG1, imm_opnd(1)); /* 生成sar汇编语句 */
    mov(cb, RSI, REG1); /* 生成 mov 汇编语句 */
    call_ptr(cb, REG0, (void *)rb_ary_entry_internal); /* 生成call汇编语句，调用实际的rb_ary_entry_internal函数 */

    x86opnd_t stack_ret = ctx_stack_push(ctx, TYPE_UNKNOWN);
    mov(cb, stack_ret, RAX); /* 生成mov汇编语句，把 rb_ary_entry_internal 的返回值(RAX寄存器的值)存入YARV虚拟机的栈顶 */

    jit_jump_to_next_insn(jit, ctx); /* 生成jmp汇编语句，继续执行后续的字节码生成的汇编语句 */
    return YJIT_END_BLOCK;
  }
  else if (CLASS_OF(comptime_recv) == rb_cHash) { 
    /* 参数类型是Hash， 生成对应汇编语句，省略 */
  }
  else {
    /* 参数类型是Proc, lambda 等, 生成对应汇编语句，省略 */
  } 

  /* 省略 */
}

static void
defer_compilation(
    jitstate_t *jit,
    ctx_t *cur_ctx
)
{
  /* 省略 */

  /* 调用get_branch_target 获取stub空壳汇编代码的内存地址, 详情见下方函数 */
  branch->dst_addrs[0] = get_branch_target(branch->targets[0], &next_ctx, branch, 0);

  /* 省略 */
}

static uint8_t *
get_branch_target(
    blockid_t target,
    const ctx_t *ctx,
    branch_t *branch,
    uint32_t target_idx
)
{
  /* 省略 */

  uint8_t *stub_addr = cb_get_ptr(ocb, ocb->write_pos);

  mov(ocb, C_ARG_REGS[2], REG_EC); /* 生成mov汇编代码，传REG_EC参数给branch_stub_hit */
  mov(ocb, C_ARG_REGS[1], imm_opnd(target_idx)); /* 生成mov汇编代码，传target_idx参数给branch_stub_hit */
  mov(ocb, C_ARG_REGS[0], const_ptr_opnd(branch)); /* 生成mov汇编代码，传branch指针参数给branch_stub_hit */
  call_ptr(ocb, REG0, (void *)&branch_stub_hit); /*  生成call汇编代码，调用branch_stub_hit函数, 详情见下方函数 */

  jmp_rm(ocb, RAX); /* 生成jmp汇编代码，跳转到branch_stub_hit的返回值地址 */

  return stub_addr;

  /* 省略 */
}

/* 如果该函数被执行，说明执行时对应的空壳汇编代码也被执行，需要生成实际的汇编代码 */
static uint8_t *
branch_stub_hit(branch_t *branch, const uint32_t target_idx, rb_execution_context_t *ec)
{
  /* 省略 */

  /* 生成实际的汇编代码(gen_block_version会重新调用gen_opt_aref)，gen_block_version在之前的gen_entry_point函数中也出现过 */
  p_block = gen_block_version(target, target_ctx, ec);

  /* 省略 */

  dst_addr = p_block->start_addr;

  /* 省略 */

  return dst_addr;
}

Basic Block Versioning

Basic Block Versioning 原理是把每段汇编代码缓存起来，形成用变量类型作为 key，汇编代码作为 value 的缓存。

ruby，js 等动态类型的语言，同一个操作可以使用不同类型的变量。还是以字节码opt_aref对应的 ruby 源码[]为例子，可以作用在 Array, Hash, Proc/lambda等变量类型上, 例如如下代码

rec = [1, 2, 3]
puts rec[2]

rec = { 1 => 1, 2 => 2 }
puts rec[2]

rec = Proc.new { |n| puts n }
rec[2]

所以 opt_aref 字节码对应的 c 源码有复杂的类型检查。Basic Block Versioning 的优化思路是，为当前变量类型生成特定的汇编代码，缓存下来。下次再遇到同样的字节码时，先检查变量类型，尝试从缓存中获取已有汇编代码内存地址；如果找不到缓存，再为新的变量类型，新增汇编代码，缓存下来。这样最终生成的汇编代码就只针对特定变量类型，易复用的同时更精简

以上面的 get_branch_target 和 branch_stub_hit 函数为例，他们都先调用 find_block_version 尝试从缓存中获取汇编代码，精简后如下

static uint8_t *
get_branch_target(
    blockid_t target,
    const ctx_t *ctx,
    branch_t *branch,
    uint32_t target_idx
)
{
  /* 省略 */

  /* 如果从缓存中找到对应的汇编代码,直接返回汇编代码内存地址, find_block_version 函数详情见下方 */
  block_t *p_block = find_block_version(target, ctx);

  // If the block already exists
  if (p_block) {
      /* 省略 */

      /* 命中缓存，返回缓存汇编代码地址 */
      return p_block->start_addr;
  }
  /* 未命中缓存，生成空壳汇编代码 */

  /* 省略 */

  uint8_t *stub_addr = cb_get_ptr(ocb, ocb->write_pos);

  mov(ocb, C_ARG_REGS[2], REG_EC); /* 生成mov汇编代码，传REG_EC参数给branch_stub_hit */
  mov(ocb, C_ARG_REGS[1], imm_opnd(target_idx)); /* 生成mov汇编代码，传target_idx参数给branch_stub_hit */
  mov(ocb, C_ARG_REGS[0], const_ptr_opnd(branch)); /* 生成mov汇编代码，传branch指针参数给branch_stub_hit */
  call_ptr(ocb, REG0, (void *)&branch_stub_hit); /*  生成call汇编代码，调用branch_stub_hit函数, 详情见下方函数 */

  jmp_rm(ocb, RAX); /* 生成jmp汇编代码，跳转到branch_stub_hit的返回值地址 */

  return stub_addr;

  /* 省略 */
}

/* 如果该函数被执行，说明可能对应的空壳汇编代码也真的被执行，需要生成实际的汇编代码 */
static uint8_t *
branch_stub_hit(branch_t *branch, const uint32_t target_idx, rb_execution_context_t *ec)
{
  /* 省略 */

  /* 尝试从缓存中找汇编代码，find_block_version 函数详情见下方 */
  block_t *p_block = find_block_version(target, target_ctx);

  /* 如果从缓存中没有找到汇编代码，生成新汇编代码 */
  if (!p_block) {

    /* 生成实际的汇编代码(gen_block_version会重新调用gen_opt_aref)，gen_block_version在之前的gen_entry_point函数中也出现过 */
    p_block = gen_block_version(target, target_ctx, ec);

    /* 省略 */
  }

  /* 省略 */

  dst_addr = p_block->start_addr;

  /* 省略 */

  return dst_addr;
}

static block_t *
find_block_version(blockid_t blockid, const ctx_t *ctx)
{
    /* 获取该字节码的所有缓存 */
    rb_yjit_block_array_t versions = yjit_get_version_array(blockid.iseq, blockid.idx);

    block_t *best_version = NULL;
    int best_diff = INT_MAX;

    /* 找出最匹配的缓存 */
    rb_darray_for(versions, idx) {
        block_t *version = rb_darray_get(versions, idx);
        int diff = ctx_diff(ctx, &version->ctx); /* 比较当前变量类型和缓存变量类型的差异, 详情见下方函数 */

        if (diff < best_diff) {
            best_version = version; /* 找出最匹配的缓存 */
            best_diff = diff;
        }
    }

    /* 省略 */

   return best_version;
}

static int
ctx_diff(const ctx_t *src, const ctx_t *dst)
{
    /* 省略 */

    /* 栈顶变量数量不同，放弃匹配 */
    if (dst->stack_size != src->stack_size)
        return INT_MAX;

    /* sp偏移量不同，放弃匹配 */
    if (dst->sp_offset != src->sp_offset)
        return INT_MAX;

    // Difference sum
    int diff = 0;

    // Check the type of self
    int self_diff = type_diff(src->self_type, dst->self_type);

    /* self 类型不同，放弃匹配 */
    if (self_diff == INT_MAX)
        return INT_MAX;

    diff += self_diff;

    // For each local type we track
    for (size_t i = 0; i < MAX_LOCAL_TYPES; ++i)
    {   
        val_type_t t_src = src->local_types[i];
        val_type_t t_dst = dst->local_types[i];
        int temp_diff = type_diff(t_src, t_dst);

        /* 本地变量类型不同，放弃匹配 */
        if (temp_diff == INT_MAX)
            return INT_MAX;

        diff += temp_diff;
    }

    /* 临时推到栈顶的变量类型 */
    for (size_t i = 0; i < src->stack_size; ++i)
    {   
        temp_type_mapping_t m_src = ctx_get_opnd_mapping(src, OPND_STACK(i));
        temp_type_mapping_t m_dst = ctx_get_opnd_mapping(dst, OPND_STACK(i));

        /* 省略 */

        int temp_diff = type_diff(m_src.type, m_dst.type);

        /* 临时变量类型不同，放弃匹配 */
        if (temp_diff == INT_MAX)
            return INT_MAX;

        diff += temp_diff;
    }

    return diff;
}

综上，Lazy Basic Block Versioning(LBBV) 就是利用【懒生成】和【变量类型缓存汇编】的 jit 优化方法。本文只浅析了大致原理，具体如何将汇编代码写入缓存，如何把不同缓存的汇编代码用 jmp 拼接在一起，如何处理分支 jmp 跳转，感兴趣的同学可自行深入浏览源码。

缓存

根据Computer System A Programmer's Perspective(深入理解计算机系统)，从硬件角度，本地硬盘是远端数据的缓存，内存是本地硬盘的缓存，CPU L1,L2,L3 是内存的缓存

以我个人的知识经验：

从操作系统的角度，内存是文件系统的缓存 (系统调用 fflush, fsync), TLB 是虚拟内存地址到物理内存地址的缓存。

从 Web 服务器的角度，数据库索引是用于查找和排序的缓存，数据库视图是用于统计的缓存，数据库 MVCC 是事务中原数据的快照/缓存，redis 等又是数据库的缓存，cdn 又是 web 服务器的缓存，HTTP 的 ETag, last-modified 又是浏览器到服务器间的缓存。

从 Ruby 语言的角度，之前同样是 Shopify 开发的 bootsnap, 用覆盖 Kernel#require 的方式实现了 Gem 文件相对文件路径到绝对文件路径的缓存; 用 RubyVM::InstructionSequence.load_iseq 实现了 Ruby 源码到字节码的缓存。而本文的 YJIT 则实现了字节码到汇编代码的缓存。

“计算机科学只存在两个难题：缓存失效和命名。” ——Phil KarIton

Ruby require 与动态链接库

zhuoerri — Sun, 08 Aug 2021 07:56:42 +0800

前言

本人水平有限，如有错误，欢迎指正与补充。

本文会先介绍 require 的基本使用，然后介绍动态链接库的基本知识。

最后深入 ruby 源码，查找对 dlopen, dlsym 的调用

require

ruby 里加载第三方 gem 的方式，通常是用 require 加载其 lib/ 文件夹下的某 .rb 文件。

但除了.rb 文件，gem 内也可以包含 c 语言写的源码，源码入口函数名往往是例如 Init_xxx 的格式。当我们用 gem install 安装 gem 的过程中，c 源码被编译成，例如名叫 xxx.so 的动态链接库。

最后 require 时，我们可以像加载 .rb 文件一样。用 require 'xxx.so' 加载动态链接库内的Init_xxx 函数。

动态链接库

对于不了解链接的同学，推荐《深入理解计算机系统》的第七章链接部分。或者《程序员的自我修养》也行。简单来说，链接就是把不同的 c 语言库和在一起，方便相互之间调用各自的函数与变量。

这个和的过程，可以是在编译时完成，称作静态链接。代价是最终的可执行文件较大。

这个和的过程，也可以推迟到程序启动时才完成，称作动态链接。优点是编译时，可执行文件只需记下自己依赖的库（linux 下可用 ldd 查看程序依赖哪些库），不用实际链接。等到启动时再实际链接，除了节省可执行文件的磁盘空间，也因为多个可执行文件共享同一个库，节省了内存。

这个和的过程，甚至可以在程序运行时进行。方法是调用 dlopen 函数加载动态链接库，再用 dlsym 获取动态链接库内的函数引用。

综上不难猜到，ruby require 动态链接库的过程，就是调用 dlopen 加载动态链接库，再用 dlsym 获取 Init_xxx 函数指针并调用的过程。

ruby 源码

require 对应的 c 函数是在 load.c 中的 rb_f_require , 精简省略后，主要的调用栈如下

/* load.c */

void
Init_load(void)
{
  rb_define_global_function("require", rb_f_require, 1);
}

VALUE
rb_f_require(VALUE obj, VALUE fname)
{
     /* 调用 rb_require_string */
    return rb_require_string(fname);
}

VALUE
rb_require_string(VALUE fname)
{
   /* 省略 */

  /* 调用 require_internal */
  int result = require_internal(ec, fname, 1);
}

static int
require_internal(rb_execution_context_t *ec, VALUE fname, int exception)
{
  /*  省略 */  

  /* 调用 rb_vm_call_cfuncs, 其中 load_ext 参数是回调函数，也是实际被调用的函数。path 是动态链接库的文件地址，其他的参数可以忽略 */
  handle = (long)rb_vm_call_cfunc(rb_vm_top_self(), load_ext,
                            path, VM_BLOCK_HANDLER_NONE, path);
}

static VALUE
load_ext(VALUE path)
{
  /* 调用 dln_load,  RSTRING_PTR(path)参数是把path转成字符指针类型 */
  return (VALUE)dln_load(RSTRING_PTR(path));
}

最终实际调用dlopen的函数在 dln.c 的 dln_load 中，其中有针对不同操作系统的宏判断，这里只精简显示 linux 相关的 dlopen

/* dln.c */

void*
dln_load(const char *file)
{
     /* 省略 */

     /* buf存储动态链接库的入口函数名，即例子中的 Init_xxx */
    char *buf;
    init_funcname(&buf, file);

    /* 调用dlopen , 获取动态链接库对应的 handle指针 */
    handle = (void*)dlopen(file, RTLD_LAZY|RTLD_GLOBAL))
    /* 调用dlsym, 获取 buf即例子Init_xxx 的函数指针*/
    init_fct = (void(*)())(VALUE)dlsym(handle, buf);
    /* 用函数指针调用 例子Init_xxx 函数 */
    (*init_fct)();
}

Rails 路由 Journey 与有限状态自动机

zhuoerri — Thu, 04 Mar 2021 13:01:04 +0800

前言

本人水平有限，如有错误，欢迎指正与补充。

Rails 路由的作用是根据 config/routes.rb 的规则，生成有限状态自动机来匹配 http 请求的路径，找到对应的 controller 与 action。然后将 rack 的请求转给 controller 的 action

本文主要介绍有限状态自动机的部分，Mapper 以及 RouteSet 只会一笔带过，论坛里早已有过分析 Mapper 和 RouteSet 等源码的帖子，感兴趣的同学可阅读下面的链接。

https://ruby-china.org/topics/22726

https://ruby-china.org/topics/30916

https://ruby-china.org/topics/34110

https://ruby-china.org/topics/30929

Mapper

config/routes.rb 里各种方法的源码主要在 actionpack/lib/action_dispatch/routing/mapper.rb 里，例如最常用的 resources 方法就定义在 mapper.rb 里。

Racc 与抽象语法树

Mapper 里识别了路径后，再用 Racc 根据 actionpack/lib/action_dispatch/journey/parser.y 自动生成的 actionpack/lib/action_dispatch/journey/parser.rb。来生成以 Journey::Nodes::Node 为节点的抽象语法树。例如如下代码

ActionDispatch::Journey::Parser.new.parse("/users/new")

#<ActionDispatch::Journey::Nodes::Cat:0x0055a9bd16a0a0
 @left=#<ActionDispatch::Journey::Nodes::Slash:0x0055a9bd16a4d8 @left="/", @memo=nil>,
 @memo=nil,
 @right=
  #<ActionDispatch::Journey::Nodes::Cat:0x0055a9bd16a0f0
   @left=#<ActionDispatch::Journey::Nodes::Literal:0x0055a9bd16a3c0 @left="users", @memo=nil>,
   @memo=nil,
   @right=
    #<ActionDispatch::Journey::Nodes::Cat:0x0055a9bd16a140
     @left=#<ActionDispatch::Journey::Nodes::Slash:0x0055a9bd16a2f8 @left="/", @memo=nil>,
     @memo=nil,
     @right=#<ActionDispatch::Journey::Nodes::Literal:0x0055a9bd16a1e0 @left="new", @memo=nil>>>>

整理一下返回结果，画成图如下

Journey

语法树

Journey 把每个路由规则的小语法树，拼成一个大语法树，以 Node::Or 作为 root 节点，例如如图。

有限状态自动机

以上图为例，当 http 请求的路径是/users/2 时。Journey 依次读到了的是 /, users, /, 2。当读到/, users 的这两个前缀时，从大语法树的 root 节点出发，每个子语法树 /users/new, /users, /users/:id 都匹配，这时就不知道该应该走哪个子节点来匹配。

这种处于某个节点状态，根据输入的数据能转移到多个子节点，不确定应该转到哪个节点才能匹配的图，就是不确定的有限状态自动机 nfa.

nfa 转 dfa

不确定有限状态自动机是可以转为确定的有限状态自动机 dfa(每个输入能确定跳转到唯一的目标节点)，原理就是把多个不确定有限状态自动机的节点，组成一个集和，作为一个新状态。这个新状态作为确定的有限状态自动机里的节点状态。例如下图

左边是不确定的有限状态自动机，右边是对应的确定的优先状态自动机。黄色节点为接受状态节点。左右都可以识别 12，13，124，134 这四个字符串。但左边的 a 节点读取到 1 时，不能确定跳转到 b，还是 c。而右边节点的 A，读取到 1 时，直接确定跳转到 B。所以右边的 B 对应左边的 [b, c]。右边其他节点同理。

Journey::GTG::TransitionTable

rails 里把整个 Nodes::Node 的 nfa 转为 TransitionTable 的 dfa，源码在 Journey::GTG::Builder.transition_table , 省略精简后，主要逻辑如下

def transition_table
  # dtrans 用来存储最终的 dfa
  dtrans   = TransitionTable.new

  # 给新生成的dfa节点赋值一个id
  state_id = Hash.new { |h, k| h[k] = h.length }.compare_by_identity

  # root 是 nfa的根节点，dstates里存储了从根节点出发，能转移到的所有节点组成的出发节点数组
  dstates  = [firstpos(root)]

  until dstates.empty?
    s = dstates.shift

    s.group_by { |state| symbol(state) }.each do |sym, ps|
      # u是一个数组，对应原nfa中所有可能跳转到的目标节点数组
      u = ps.flat_map { |l| @followpos[l] }.uniq
      next if u.empty?

      # from是新建的dfa里的出发节点，对应原nfa里s出发节点数组
      from = state_id[s]

      # 如果所有nfa中的目标节点数组中节点都是接受节点
      if u.all? { |pos| pos == DUMMY_END_NODE }
        # 创建一个新 dfa 节点
        to = state_id[Object.new]
        # 写入dfa中，从from节点，读取到sym后，进入to节点
        dtrans[from, to] = sym
        # 把to节点标记为接受节点
        dtrans.add_accepting(to)

      else
        # 根据nfa的u节点数组，读取或新建对应的dfa节点to
        to = state_id[u]
        # 写入dfa中，从from节点，读取到sym后，进入to节点
        dtrans[from, to] = sym

        if u.include?(DUMMY_END_NODE)
          # 如果u节点数组中有接受节点，把to节点标记为接受节点
          dtrans.add_accepting(to)
        end
      end

      # 把u节点数组作为出发节点，继续循环
      dstates << u
    end

处理 rack 请求

router 收到 rack 请求后，会尝试用上面的 TransitionTable 来匹配 req.path_info。匹配的源码主要在 Journey::GTG::Simulator#memos

def memos(string)
    # input 是要匹配的路径，例如 /users/new
    input = StringScanner.new(string)

    # INITIAL_STATE = [ [0, nil] ].
    # dfa 的初始节点状态，即0 
    state = INITIAL_STATE

    start_index = 0

    while sym = input.scan(%r([/.?]|[^/.?]+))
      end_index = start_index + sym.length

     # tt是TransitionTable
     # 从state节点出发，读取到 string[start_index, end_index] 后，跳转的目标节点又赋值给state
      state = tt.move(state, string, start_index, end_index)

      start_index = end_index
    end

    # 如果最终有可接受节点，返回节点信息。否则 yield
    acceptance_states = state.each_with_object([]) do |s_d, memos|
      s, idx = s_d
      memos.concat(tt.memo(s)) if idx.nil? && tt.accepting?(s)
    end

    acceptance_states.empty? ? yield : acceptance_states
  end

之后 router 根据节点里存的 controller 和 aciton 信息，把 rack 请求转给对应的 controller

总结

本文只讲了有限状态机，具体的判断逻辑其实更复杂，例如 /users/:id 这种 :id 参数名，dfa 匹配时需要考虑正则表达式。但本文都省略了，感兴趣的同学可以自行深入浏览源码。

最后推荐一本书的前半部分（因为我只读了前半部分）《计算的本质》，前半部分用 ruby 语言实现了简单的词法分析器与语法分析器。虽然从编译原理的角度看不够专业，但特别适小白合作为看 Rails 路由 Journey 前的预备资料。

head 请求绕过 Github 的 OAuth

zhuoerri — Fri, 20 Dec 2019 19:13:57 +0800

看阮一峰老师的科技爱好者周刊，提到的

https://blog.teddykatz.com/2019/11/05/github-oauth-bypass.html

zhuoerri (秦阳)

Object Shapes 浅析

前言

Shape Tree

Inline Cache

红黑树

参考资料

垃圾回收原理浅析

前言

Ruby 内存模型

Q: Ruby 对象在内存里是怎么存储管理的？

Q: 还是不懂，能打个比方吗？

Q: 如果【工位】(slot) 不够了？

Q: 如果裁员后【工位】(slot) 还是不够？

Q: 什么时候退租【办公室】(page),还内存给操作系统？

Q: 怎么判断哪些【员工】(Ruby对象) 是无用的，需要被裁？

标记回收算法

Q: 标记回收算法的流程是怎样的？

Q: 每次裁员要从头问一遍所有人，有什么办法优化吗？

分代回收

Q: 分代回收算法的流程是怎样的？

Q: 哪些【员工】(Ruby对象) 会默认有用？

Q: 上面的例子，如果在第三次裁员后，第四次裁员前，新招了一个新员工 E，某个【老员工】(old object) 觉得新员工 E 有用。但 HR 跳过了老员工的询问，不知道员工 E 有用，第四次裁员时误裁掉员工 E。怎么办？

Q: 所有的员工都会这么主动帮新员工吗？

Q: 那怎么办？

Q: 【小裁员】(minor) 跳过【老员工】(old object) 减少了标记的时间。但【大裁员】(major/full) 依然要问一遍所有人，有什么办法优化【大裁员】(major/full) 吗？

增量回收

Q: 增量回收算法是怎么优化【大裁员】(major/full) 流程的？

Q: 和分代回收时同样的问题：如果某个员工 A 被标记为【已标记】(black object), 然后新招了一个员工 B，员工 A 觉得员工 B 有用。但因为 HR 不会再询问员工 A 了，不知道员工 B 有用，导致员工 B 被误裁，怎么办？

Q: 所有的员工都会主动帮新员工吗？

Q：那怎么办？

Q: 所以一个【员工】(Ruby对象) 总共有哪些标记？

Q: 裁员完后，不换一下工位，让员工间坐得更近，空出更多的【办公室】(page) 吗？

碎片整理

Q: 碎片整理算法的流程是怎样的？

Q: 所有员工都会乖乖换工位吗？

Q: 碎片整理除了空出更多的【办公室】(page), 还有别的好处吗？

局部性原理

Q: 什么是局部性原理？

Q: 除了碎片整理，Ruby 垃圾回收中还有哪些优化用到了局部性原理吗？

Q: 除了垃圾回收，Ruby 中还有哪些优化用到了局部性原理吗？

YJIT 打算用 Rust 重写

Ruby YJIT 原理浅析

前言

字节码

JIT

YJIT

Lazy Basic Block Versioning (LBBV)

Lazy

Basic Block Versioning

缓存

Ruby require 与动态链接库

前言

require

动态链接库

ruby 源码

Rails 路由 Journey 与 有限状态自动机

前言

Mapper

Racc 与抽象语法树

Journey

语法树

有限状态自动机

nfa 转 dfa

Journey::GTG::TransitionTable

处理 rack 请求

总结

head 请求绕过 Github 的 OAuth

Q: 如果【工位】(`slot`) 不够了？

Q: 如果裁员后【工位】(`slot`) 还是不够？

Q: 什么时候退租【办公室】(`page`),还内存给操作系统？

Q: 怎么判断哪些【员工】(`Ruby对象`) 是无用的，需要被裁？

Q: 哪些【员工】(`Ruby对象`) 会默认有用？

Q: 上面的例子，如果在第三次裁员后，第四次裁员前，新招了一个新员工 E，某个【老员工】(`old object`) 觉得新员工 E 有用。但 HR 跳过了老员工的询问，不知道员工 E 有用，第四次裁员时误裁掉员工 E。怎么办？

Q: 【小裁员】(`minor`) 跳过【老员工】(`old object`) 减少了标记的时间。但【大裁员】(`major/full`) 依然要问一遍所有人，有什么办法优化【大裁员】(`major/full`) 吗？

Q: 增量回收算法是怎么优化【大裁员】(`major/full`) 流程的？

Q: 和分代回收时同样的问题：如果某个员工 A 被标记为【已标记】(`black object`), 然后新招了一个员工 B，员工 A 觉得员工 B 有用。但因为 HR 不会再询问员工 A 了，不知道员工 B 有用，导致员工 B 被误裁，怎么办？

Q: 所以一个【员工】(`Ruby对象`) 总共有哪些标记？

Q: 裁员完后，不换一下工位，让员工间坐得更近，空出更多的【办公室】(`page`) 吗？

Q: 碎片整理除了空出更多的【办公室】(`page`), 还有别的好处吗？

Rails 路由 Journey 与有限状态自动机