max_semi_space_size 设置值与实际值不一致的原因分析

问题由来

因为业务的需求，某 Node.js 性能平台用户需要调节新生代大小，Node.js 的启动参数里面的max_semi_space_size可以设置新生代堆空间的大小。

node --v8-options | grep max_semi -A 3 -B 2--min_semi_space_size (min size of a semi-space (in MBytes), the new space consists of twosemi-spaces)type: int  default: 0--max_semi_space_size (max size of a semi-space (in MBytes), the new space consists of twosemi-spaces)type: int  default: 0--semi_space_growth_factor (factor by which to grow the new space)type: int  default: 2

相关文档里该值是一个以MB为单位的整数，并没有其他特别的约束。

然而，当用户设置 max_semi_space_size 为200时，Node.js 性能平台 GC Trace分析 结果显示 inactive new_space semispace:256MB，说明新生代中未使用的那部分是256MB（有关GC的一些知识可以参阅文档最后的列表），如下图所示。

我们也线下验证了一下：

当设置 max_smi_space_size 为100,110时，inactive new_space semispace:128MB。
当设置 max_smi_space_size 为50,60时，inactive new_space semispace:64MB。

那么问题来了，是 Node.js 性能平台的bug？还是v8引擎本身的设计就是如此？

问题定位

其实，从最终64/128/256，这些数值就能推测到，设计就是如此。在计算机的世界里，2的整数次幂会带来很多方便。

还是老方法，既然文档里没有明确说明，而 Node.js 性能平台运行时在该部分功能跟社区运行时是完全一致的，那么只能去代码里找原因了。
一番操作之后，在 deps/v8/src/heap/heap.cc 中找到函数：

bool Heap::ConfigureHeap(size_t max_semi_space_size, size_t max_old_space_size, size_t code_range_size))。

这里摘抄一点max_semi_space相关代码，相关注释直接写到代码里面了，感兴趣的同学建议去看看完整代码。

bool Heap::ConfigureHeap(size_t max_semi_space_size, size_t max_old_space_size,size_t code_range_size) {if (HasBeenSetUp()) return false;// Overwrite default configuration.// 未设置 max_semi_space_size 时，默认值是 0 if (max_semi_space_size != 0) {max_semi_space_size_ = max_semi_space_size * MB;}...// If max space size flags are specified overwrite the configuration.// 命令行 --max_semi_space_size 设置的新生代大小是通过 FLAG_max_semi_space_size 传递到vif (FLAG_max_semi_space_size > 0) {max_semi_space_size_ = static_cast<size_t>(FLAG_max_semi_space_size) * MB;}.../* ROUND_UP 的定义:// Round up n to be a multiple of sz, where sz is a power of 2.#define ROUND_UP(n, sz) (((n) + ((sz) - 1)) & ~((sz) - 1))*/// 操作系统相关的内存页大小，我的ubuntu16.04上该值是 512KBif (Page::kPageSize > MB) {max_semi_space_size_ = ROUND_UP(max_semi_space_size_, Page::kPageSize);...}// 该参数默认是falseif (FLAG_stress_compaction) {// This will cause more frequent GCs when stressing.max_semi_space_size_ = MB;}// The new space size must be a power of two to support single-bit testing// for containment.// 关键点在这里// 为什么 50 变成了 64， 100/120 变成了128， 200 变成了 256// 下面的函数 RoundUpToPowerOfTwo32 就是这个变化的原因。/*
uint32_t RoundUpToPowerOfTwo32(uint32_t value) {DCHECK_LE(value, uint32_t{1} << 31);if (value) --value;
// Use computation based on leading zeros if we have compiler support for that.
#if V8_HAS_BUILTIN_CLZ || V8_CC_MSVCreturn 1u << (32 - CountLeadingZeros32(value));
#elsevalue |= value >> 1;value |= value >> 2;value |= value >> 4;value |= value >> 8;value |= value >> 16;return value + 1;
#endif
}*/ max_semi_space_size_ = base::bits::RoundUpToPowerOfTwo32(static_cast<uint32_t>(max_semi_space_size_));// 这里是 min_semi_space_size 的设置，这里不讨论if (FLAG_min_semi_space_size > 0) {...}// 新生代初始大小是 min_semispace_size，如果需要，那么增大到 max_semi_space_sizeinitial_semispace_size_ = Min(initial_semispace_size_, max_semi_space_size_);if (FLAG_semi_space_growth_factor < 2) {FLAG_semi_space_growth_factor = 2;}...configured_ = true;return true;
}

问题结论

max_semi_space_size 设置看起来是个任意整数，但是实际使用中 v8 会把该值转换成一个不小于该值的2的整数次幂的值。也就是说：

max_semi_space_size 设置为 33, 34, ..., 64，最终结果都是 64MB。
max_semi_space_size 设置为 65, 66, ..., 128，最终结果都是 128MB。
依次类推

heap.cc 里面的注释是

  // The new space size must be a power of two to support single-bit testing// for containment.