<aside> 📖 Freestanding 环境下也可以使用的定义

• stddef.h - size_t
• stdint.h - int32_t, uint64_t
  • int和long的长度并不固定，这为可移植性带来了很大的障碍
  • printf其实也有portable的写法
  • intptr_t 保存指针
• stdbool.h - bool, true, false
• float.h
• limits.h
• stdarg.h
  • syscall 就用到了 (但 syscall0, syscall1, ... 更高效)
• inttypes.h

读读 man exec

</aside>

封装 (1): 纯粹的计算

string.h: 字符串/数组操作

标准库只对 “标准库内部数据” 的线程安全性负责****

• memset不管，printf的buffer要负责

封装 (2): 文件描述符

<aside> 📖 File Desciptor

FILE * 背后其实是一个文件描述符

我们可以用 gdb 查看具体的 FILE * (例如 stdout)

可以 “窥探” 到 glibc 的一些内部实现

可以加载 glibc 的 debug symbols

封装了文件描述符上的系统调用 (fseek, fgetpos, ftell, feof, ...)

</aside>

<aside> 📖 popen 和 pclose

一个设计有缺陷的 API

Since a pipe is by definition unidirectional, the type argument may specify only reading or writing, not both; the resulting stream is correspondingly read-only or write-only.

</aside>

封装 (3): 更多的进程/操作系统功能

err, error, perror

environ 被glibc init赋值

封装 (4): 地址空间

<aside> 📖 脱离 workload 做优化就是耍流氓

在开始考虑性能之前，理解你需要考虑什么样的性能

</aside>

<aside> 📖 指导思想

$O(n)$ 大小的对象分配后至少有 $\Omega (n)$ 的读写操作，否则就是 performance bug (不应该分配那么多)

• 越小的对象创建/分配越频繁
  • 字符串、临时对象等 (几十到几百字节)；生存周期可长可短
• 较为频繁地分配中等大小的对象
• 较大的数组、复杂的对象；更长的生存周期
• 低频率的大对象
• 巨大的容器、分配器；很长的生存周期
• 并行、并行、再并行
• 所有分配都会在所有处理器上发生
• 使用链表/区间树 (first fit) 可不是个好想法 </aside>

<aside> 📖 设置两套系统

fast path

• 性能极好、并行度极高、覆盖大部分情况
• 但有小概率会失败 (fall back to slow path)

slow path

• 不在乎那么快
• 但把困难的事情做好

计算机系统里有很多这样的例子 (比如 cache)

小内存：Segregated List

• 分配: Segregated List (Slab)
  • 每个 slab 里的每个对象都一样大
  • 每个线程拥有每个对象大小的 slab
  • fast path → 立即在线程本地分配完成
  • slow path → pgalloc()
  • 两种实现
    • 全局大链表 v.s. List sharding (per-page 小链表)
• 回收
  • 直接归还到 slab 中
  • 注意这可能是另一个线程持有的 slab，需要 per-slab 锁 (小心数据竞争

大内存：一把大锁保平安

• Buddy system (1963)
• 如果你想分配 1, 2, 3, 4, ... 个连续的页面？
  • 例如：64 KB/页面
• 那就 first fit 或者 best fit 吧……
  • 你只需要一个数据结构解决问题
  • 区间树；线段树…… </aside>