这一章会介绍Orinoco垃圾回收器对应知识，之前垃圾回收是有序执行，stop-the-world（STW），Orinoco垃圾回收器是一个在大部分情况下进行并行以及并发运作，来快速的进行垃圾回收。下面是相关视频的介绍
我们都清楚任何垃圾回收器都有一些周期性需要完成的工作
- 识别存活/死亡的对象
- 回收/重用死亡对象占用的内存空间
- 压缩/回收内存空间
怎样去优化长任务
在web前端中，我们总是会听说不要阻塞主线程，我们要打断长任务的运行。做这些事情的意义到底在哪里？
如果我们看过很多关于web 性能优化的文章，我们会发现保持我们的javascript 应用程序变快的建议中往往都会提到如下的建议：
- 不要阻塞主线程
- 把长任务打断
我们在加载的页面的时候，基本上都会去考虑怎么减少javascript 代码的体积，这个能够提高页面打开的速度，但是更少的代码并不一定意味着用户的界面体验会更流畅。
要懂得优化js中任务的重要性。那么我们首先需要了解什么是任务，任务的角色，以及浏览器是怎么处理任务的。我们先来了解一下什么是任务?
什么是任务
浏览器执行的各个任务之间是相互独立的。例如页面渲染，解析html和css,运行我们编写的javascript代码，以及一些我们无法直接控制的事情都输入任务的范畴。但是浏览器中任务的主要来源是我们编写和部署的代码。
任务影响性能的方式很多，比如我们在打开网站时下载js代码，浏览器会把任务放在队列中，当解析编译javascript完成执行，再去排队执行任务。随后页面的任务会随着用户交互驱动的事件处理器，js动画以及分析收集的后台活动等js活动触发（web worker 等类似的api除外）。
什么是主线程
浏览器中大多数任务都发生在主线程中。主线程之所以被称为主线程的一个主要原因是：我们写的javascript代码几乎都在该线程上执行。
在同一时刻，主线程只能运行一个任务。当该任务的执行时间超过50ms的时候，那么这个任务就会被称之为长任务（long task）。当一个长任务正在运行的过程中，这个时候用户也在与页面进行交互，或者这个时候有个关键的渲染更新需要进行。这个时候，浏览器会延迟用户交互或者渲染。这个时候导致用户交互或渲染延迟，也是就页面发生卡顿。
阅读 “怎样去优化长任务” itemprop="discussionURL"发表评论通过视觉图灵测试：我们在VR中追求视觉真实性的内部故事
这是facebook VR 实验室在探索VR视觉效果的心路历程：深度分享变焦、畸变、高分辨率、HDR等原型设计和研发。原文链接如下：Passing the visual Turing test: The inside story of our quest for visual realism in VR
2002年11月的时候，Meta的公司ceo 马克·扎克伯格给 CTO Andrew 和 虚拟现实实验室的首席科学家 Michael Abrash 发了一封邮件，开门见山的问了一个问题：“是什么让我们无法拥有与现实几乎无法区分的VR显示器，为了实现这一目标，我们必须解决什么问题?”
这是扎克伯格和阿布拉什多年来就构建高级虚拟现实（VR）显示系统进行的一系列详细对话中最近的一次。从2015年前往一家前景满满的增强现实公司，到频繁的电子邮件、一对一讨论和技术评论，再到多年来在雷德蒙德和门罗公园的多次演示，这是扎克伯格和亚伯拉什就构建先进虚拟现实显示系统进行的又一次详细对话。
我们可能认为两人对问题的回答可能只是纸上谈兵–但事实并非如此，因为显示实验室的显示系统研究（DSR）团队在道格拉斯-兰曼（Douglas Lanman）的领导下，在过去五年里一直在对回答扎克伯格的具体问题所需的所有技术进行深入研究。事实上，这正是在正确的时间提出了正确的问题，使DSR对未来十年的VR显示的愿景得以具体化和规划：通过视觉图灵测试。
阅读 “通过视觉图灵测试：我们在VR中追求视觉真实性的内部故事” itemprop="discussionURL"发表评论css网格布局中auto-fill与auto-fit的不同点
css grid 布局中 我们不仅可以明确列的大小，也可以通过repeat 来重复填充子项。具体的来说，我们可以指定网格中需要多少列，然后让浏览器来处理响应性。不需要写媒体查询，我们就能够在较小的视口尺寸下显示较小的列，在较宽的屏幕空间中显示更多的列。
只需要一行css就能够做大这一点。这种神奇的、无需媒体查询的响应能力是通过repeat()函数和自动定位关键词实现的。
总而言之，repeat()函数允许我们根据需要重复列的次数。假如，我们需要创建一个12列的网格，我们可以写下面的代码。
.grid {
display: grid;
/* define the number of grid columns */
grid-template-columns: repeat(12, 1fr);
}
这行代码的目的时候，将空间平均的分为12列，每列的宽度均等。每列的宽度会随空间的大小而变化。如果视口宽度比较少的话，那么列就会变的特别小。怎么解决这个问题呢。这个时候可以使用minmax()这个函数，来解决这个问题。
如下面代码所示grid-template-columns:repeat(12, minmax(200px, 1fr));
这样我们保证了每列在小视口宽度的时候，最小宽度有200px，但是这样会导致一个问题，由于列数为12列，那么每行的知识长度有2400px，这样在视口宽度小的屏幕会导致溢出屏幕。如下视频所示：
网格布局完全指南
网格布局
这个是css网格布局的完全指南，涉及到网格布局的父元素属性说明，以及网格布局的子元素属性说明。
内容列表
网格布局介绍
css 网络布局也就是Grid 或css grid ,它是一个二维的布局系统，完全改变了我们过去的布局方式。css是用来布局我们的web页面，但是它有很多做到不到位的地方。最初，我们使用table ,然后是float position 还有inline-block,但是这些方法基本上是hack方式做到的，此外还不支持很多重要功能（如垂直居中）Flexbox是个很强的布局工具，但是它只是一个一维的布局方案。Grid是第一个专门为解决布局问题而创建的CSS模块，在它之前我们做网站的过程中，我们一直在用hack手段解决这些问题。在这片文章里，我不会去讲grid之前版本的相关属性。
网格布局的基础知识与浏览器支持
2017年初，几乎所有的浏览器都支持不带浏览器前缀的grid布局模型，像Chrome,Firefox Oprea 以及Safari 和IE10等，但是这个grid语法的一个过渡版本。现在gird最新属性已经发生变化了,是时候写一份新版的grid布局的指南了。
为了使网格布局开始工作，我们需要利用display:grid 这个样式将一个元素作为网格布局的容器。利用 gird-template-columns和grid-template-rows来设置行与列的尺寸，然后使用gird-column 和grid-row将子元素放入网格中。这个与flexbox布局很相似，每个gird 子项的位置并不重要。我们可以使用的CSS属性按任何顺序放置它们，这样用媒体查询重新安排的网格布局变得非常容易。我们可以想象一下，定义整个页面的布局，然后完全重新排列以适应不同的屏幕宽度，只需几行CSS即可。网格是有史以来最强大的CSS模块之一。
下面的图片是从Caniuse中获取的数据，Caniuse中能够查询到各个浏览器对gird支持更详细的数据。
Desktop支持
Mobile/Tablet 支持
纤程，线程
我们的操作系统需要运行各种各样程序，为了程序的管理，进行了各种各样的抽象，对内存的管理，抽象了虚拟内存，对程序抽象出了进程。随着cpu核心的增多，进程的抽象有点笨重，主要原因是
- 创建进程的开销比较大，父子进程之间需要拷贝的东西比较多，虽然为解决内存共享的一些问题，提出了写时拷贝技术，但是写时拷贝会造成延时
- 进程之间通信的开销高，共享数据和同步数据比较麻烦
闲聊 v8 GC的进化(2)
垃圾回收的运行会阻断渲染进程的运行，这会影响浏览器的体验。V8引擎的开发者打算优化v8的垃圾回收模块，优化的垃圾收集器代号为Orinoco。Orinoco与之前未优化的垃圾回收器相比
- 实现一个主要是并行和并发的垃圾收集器
- 模糊代际边界（主要是新生代对象和老生代对象）
- 减少了垃圾收集的时间和内存消耗，并提高了垃圾回收的吞吐量
在这篇文章中我们讨论新的垃圾收集器的三个特性，他们分别是
- 并行compaction
- 并行记忆集处理
- 黑色分配
V8实现了代际垃圾收集器，新生代对象在经历两次回收生存下来的对象会被划分到老生代对象存储空间。对象在内存中移动的代价是很昂贵的，主要是在引擎中我们需要对象的需要复制到新的位置，此外我们还需要更新这些对象的指针。图1显示了Orinoco之前的阶段及其执行方式。基本上，对象先被移动，之后再更新这些对象之间的指针，所有这些都是按顺序进行的，消耗的时间过长。
闲聊v8垃圾回收器的演变历史（1）
javascript 是带有gc机制的语言，与c，c++ 这种需要用户手动进行内存的管理语言不同，带有gc机制的语言，我们在写代码的过程无需管理已分配的内存块，减少我们编写的代码心智成本。
chrome浏览器js引擎是v8, 起初v8的大部分垃圾回收工作是在主渲染线程上进行的。我们清楚当浏览器器在16.66ms内无法完成一帧的渲染时，那么就会出现页面卡顿现象。当GC需要维护的对象变多时，垃圾回收过程所占用的时间也会导致页面卡顿。如下图所示
