太久沒有更新blog了，慚愧下先，下邊進入正題。

      最近在實現一個閹割版的函數式語言（編譯器已完成，虛擬機在憋的過程中，之后會發帖），希望內存管理的部分由虛擬機來完成，而不是由客戶自己折騰，這樣顯然可以降低客戶使用這門語言的難度，比如不需要擔心內存泄漏，減少內存運用不當的bug，這里客戶只管放心地一直申請內存就行，不再需要手工釋放內存（如果讓客戶選擇是否自己釋放都行，會提高難度，起碼得做個平衡樹放著這些申請的內存地址便于查找，這里先偷懶）。

      首先講一下虛擬機的內存管理機制。眾所周知，頻繁地申請和釋放內存會大大降低效率，所以我們可以在虛擬機運行一開始的時候就統一申請內存，虛擬機運行結束在統一釋放內存。如果中間有某些內存已經不需要再次使用，繼續占著茅坑不拉屎是非常不道德的，于是需要對此做點事情，造成內存已釋放的“假象”。這里強調一下，虛擬機知道哪塊內存正在使用、哪塊內存不需再用就行了，實際上程序吃的內存還是沒有減少。聲明一下，下文提到的申請和釋放內存講的都是“假象”。

      如何實現這個機制呢？本能地想到引用計數，記錄下到底有多少個對象引用這塊內存，如果引用計數為0就釋放內存。后來才意識到引用計數是行不通的，萬一有環形數據結構（如一個對象自己引用自己），顯然會造成內存泄漏。然后就動了對象池的念頭，如果用這種方法，需要很多個對象池，包括虛擬機運行中的表、堆棧里的各種數據類型的對象，這么多個對象池看著很礙眼，于是還是決定實現垃圾收集器。

      下面介紹垃圾收集器的工作機制。內存單元并不會在變成垃圾的同時就立刻被回收，而是保持不可到達的狀態，直到內存被耗盡或者內存分配達到某個閾值，用戶程序會被掛起，此時才進行垃圾收集，也就是先標記正在使用的內存，再清除垃圾，即內存回收。垃圾收集器回收足夠的內存后，用戶程序就可以繼續工作。如國無法恢復足夠多的內存，則拋出異常。

1. 標記

      標記是為了識別垃圾，依靠對所有存活對象進行一次全局遍歷來確定哪些內存可以回收。這個遍歷從根出發（運行時的棧和表），利用相互引用關系，標記所有存活對象，除此之外，其他內存就是垃圾。這里強調下，標記并不會沿著已經被標記的單元追蹤下去，這確保了標記能夠終止。

2. 縮并

      用戶程序在堆上分配多種大小不同的對象，經過標記，我們發現，堆空間變得破碎，如果不擴展堆，也許就無法分配一個大型對象，因為找不到一個足夠大的“空洞”容納新的對象 ，即使空閑內存的總量是足夠的。還有另外一個問題，經過若干個垃圾收集周期后，分配一個小型對象要采用什么算法？首次匹配代價低點，但是會產生更多碎片；最佳匹配產生的碎片少了，但是耗費的代價高。這顯然提高了內存分配的難度?；谝陨系挠懻?，對內存進行縮并就是自然的事了。即把空閑的內存掃到一起，也把正在使用的內存掃到一起，這樣就把堆空間分成了兩部分。這樣空閑的內存連續了，也就解決了內存碎片的問題。當為新對象分配內存時，再也不用尋找合適的“空洞”，只需把記錄空閑內存的基點后移，大大提高了內存分配的效率。

3. 分代收集

      我們先有這樣的假設：大多數對象都在年輕的時候死亡，而越老的對象則越不可能死亡。在垃圾收集的過程中，用戶程序是被掛起的，如果對整個堆都進行垃圾收集，顯然用戶程序等待的時間是很長的。如果我們能把工作集中在回收最有可能是垃圾的對象上，就能讓內存回收的效率更高，對用戶程序的影響更小。

      基于以上假設，我們需要區分年輕對象和年老對象。把對象按年齡分到堆中的不同區域里，其中最年輕的分代會被頻繁地收集，而較老的分代則收集頻率會低得多。對象首先在最年輕的分代里分配，如果它們的壽命足夠長，能夠在足夠多次收集中存活下來（這里就是一次），則會被提升到較老的分代里。這里注意一下，較老的對象可能引用了較年輕的對象，我們仍需對此進行掃描，但是我們現在不必把年老的對象從一個半區復制到另一個半區了，將垃圾收集器的努力集中在回收最年輕的分代所占據的內存上，節省了用戶等待的時間。