Skip to content

Commit 563e16c

Browse files
committed
add v8 chapter
1 parent f2e019c commit 563e16c

File tree

2 files changed

+12
-3
lines changed

2 files changed

+12
-3
lines changed

Diff for: chapter2/chapter2-0.md

+11-2
Original file line numberDiff line numberDiff line change
@@ -103,6 +103,13 @@ Context为准的,当退出这个函数时,又恢复到了原来的Context。
103103
垃圾回收器面临的第一个问题是,如何才能在堆中区分指针和数据,因为指针指向着活跃的对象。大多数垃圾回收算法会将对象在内存中挪动(以便减少内存碎片,使内存紧凑),因此即使不区分指针和数据,我们也常常需要对指针进行改写。
104104
V8采用了标记指针法:这种方法需要在每个指针的末位预留一位来标记这个字代表的是指针或数据。
105105
106+
107+
#### 对象的晋升
108+
当一个对象经过多次新生代的清理依旧幸存,这说明它的生存周期较长,也就会被移动到老生代,这称为对象的晋升。具体移动的标准有两种:
109+
- 对象从From空间复制到To空间时,会检查它的内存地址来判断这个对象是否已经活过一次新生代的清理,如果是,则复制到老生代中,否则复制到To空间中
110+
- 对象从From空间复制到To空间时,如果To空间已经被使用了超过25%,那么这个对象直接被复制到老生代。
111+
112+
106113
#### 写屏障
107114
如果新生区中某个对象,只有一个指向它的指针,而这个指针恰好是在老生区的对象当中,我们如何才能知道新生区中那个对象是活跃的呢? 为了解决这个问题,实际上在写缓冲区中有一个列表 `store-buffer{.cc,.h,-inl.h}`,列表中记录了所有老生区对象指向新生区的情况。新对象诞生的时候,并不会有指向它的指针,而当有老生区中的对象出现指向新生区对象的指针时,我们便记录下来这样的跨区指向。由于这种记录行为总是发生在写操作时,它被称为写屏障.
108115
@@ -118,8 +125,10 @@ V8采用了标记指针法:这种方法需要在每个指针的末位预留一
118125
119126
### 总结
120127
128+
如果你还想了解更多垃圾回收上的东西,我建议你读读Richard Jones和Rafael Lins写的《Garbage Collection》,这是一个绝好的参考,涵盖了大量你需要了解的内容。你可能还对《Garbage First Garbage-Collection》感兴趣,这是一篇描述JVM所使用的垃圾回收算法的论文。
121129
122130
123131
### 参考
124-
[1]. https://developers.google.com/v8/get_started
125-
[2]. https://developers.google.com/v8/embed
132+
* https://developers.google.com/v8/get_started
133+
* https://developers.google.com/v8/embed
134+
* http://newhtml.net/v8-garbage-collection/

Diff for: chapter2/chapter2-2.md

+1-1
Original file line numberDiff line numberDiff line change
@@ -374,7 +374,7 @@ runInThisContext是将被包装后的源字符串转成可执行函数,(runI
374374
#### 总结
375375
Node.js 通过 cache 解决无限循环引用的问题, 也是系统优化的重要手段,通过以空间换时间,使得每次加载模块变得非常高效。
376376

377-
在实际的业务开发中,我们从堆的角度观察node启动模块后,缓存了大量的模块,包括第三份的模块,有的可能只加载使用一次。笔者觉得有必要有一种模块的卸载机制[1],
377+
在实际的业务开发中,我们从堆的角度观察node启动模块后,缓存了大量的模块,包括第三方的模块,有的可能只加载使用一次。笔者觉得有必要有一种模块的卸载机制[1],
378378
可以降低对 V8堆内存的占用,从而提升后续垃圾回收的效率。
379379

380380
#### 参考

0 commit comments

Comments
 (0)