关于Azul 并发垃圾回收器（更新中）

题记：

    总感觉JE讨论的帖子的东西都比较滞后，所以会有意多关注下infoQ上的东西，看看大洋彼岸的程序员们都在关心着什么。本文是说垃圾回收的，原文：http://www.infoq.com/articles/azul_gc_in_detail

根据个人体会和理解，筛选出了文章的重点.

Introduction

Automatic garbage collection frees the programmer from much of the worry about releasing objects that are no longer neededIt also prevents some kinds of common bugs occurring, including certain kinds of memory leaks, dangling pointer bugs (which occur when a piece of memory is freed while there are still pointers to it and one of those pointers is then used) and double free bugs (which occur when the program tries to free a region of memory that has already been freed and perhaps already been allocated again).

it does also have some problems. The most significant is that thus far, practical implementations of garbage collection in commercial Java runtimes have generally involved an unpredictable "pause" during collection.

但这种垃圾回收也存在一些问题，比如JVM的GC在垃圾回收过程中会不可预期地暂停应用线程#应该跟GC的单线程回收有关#

 

As Java programs have expanded in size and complexity, so the garbage collection pause has become an increasingly significant problem for Java software architects.

随着程序越来越复杂，这种回收的pause越来越频繁。

 

A widely used technique in enterprise Java to work around this is to distribute programs. This can both keep the heap size smaller, making the pauses shorter, and also allow some requests to continue whilst others are paused. Increasingly though, this means that Garbage Collector (GC) managed workloads are unable to take full advantage of the capabilities of the hardware on which they run.

 

一种普遍的解决方案是“云”，把程序拆分成集群，这样每台机器heap足够小，减少回收的次数，从而减少pause，且可持续响应用户的请求，但这样GC的回收从某种意义上来说没得到足够的利用。作者还认为当前GC的发展滞后于硬件的发展。

 

 

Collector Mechanisms

Common Tasks

要实现一个collector，必须要做到：

 

• Identifying the live objects in the memory heap 标记live内存
  
• Reclaiming the resources used by those objects that are not live (aka “dead” objects) 回收内存
  
• Periodically relocating live objects to create some amount of contiguous free space in order to accommodate the allocation of new objects of varying sizes – this process is referred to as either relocation or compaction

 

Parallelism and Concurrency

Garbage collectors can be either single-threaded or parallel:

回收可以是单线程，也可以是多线程的

• A single threaded collector uses at most one CPU core to perform garbage collection.
• A parallel collector uses multiple threads that can perform collection work at the same time, and can therefore make simultaneous use of more than one CPU core

They are also either Stop-the-world or Concurrent:

所以GC也可以是并发的

• A Stop the world collector performs garbage collection work with the application code stopped.
• A concurrent collector performs garbage collection work concurrently with program execution, allowing program execution to proceed while collection is done (potentially using separate CPU cores)这种并发的GC可以于业务代码同时运行，GC的回收不会打扰你程序的运行。

Responsiveness and Sensitivity

反应时间和敏感度

 

 

The Azul Garbage Collector

Azul's GPGC collector (which stands for Generational Pauseless Garbage Collector), included in its HotSpot-based JVM, is both parallel and concurrent. GPGC has been widely used in a number of production systems for several years now, and has been successful at removing or significantly reducing sensitivity to the factors that typically cause other concurrent collectors to pause.

 

说道这个GC在一些产品中应用了多年并成功避免了其他并发回收器的“失效”。

 

Azul用到的一些原理：

 

The Loaded Value Barrier

“Self Healing”

How the Azul Algorithm Works

详细没看了，估计看了也不太明白。

 

 

Comparison with existing Garbage Collectors

HotSpot’s Concurrent Mark Sweep (CMS) is a mostly concurrent collector. It performs some garbage collection operations concurrently with program execution, but leaves some operations to long stop-the-world pauses. Tene described it as follows:

Hotspot’s CMS collector uses a full, stop-the-world parallel new generation collector which compacts the new generation on every pass. Since young generation collection is very efficient, this stop-the-world pass typically completes very quickly - in the order of 100s of milliseconds or less.

CMS uses a mostly-concurrent collector for OldGen. It has a mostly concurrent, multipass marker that marks the heap while the mutator is running, and tracks mutations as they happen. It then revisits these mutations and repeats the marking. CMS does a final stop-the-world “catch up” marking of mutations, and also processes all weak and soft refs in a stop-the-world pause.

CMS does not compact concurrently. Instead, it does concurrent sweeping, maintains a free-list, and attempts to satisfy old generation allocations from this free list. However, because the free list is not compacted, free space will inevitably be fragmented, and CMS falls back to a full stop-the-world to compact the heap.

 

 

Oracle’s experimental Garbage First (G1) collector, which is expected to ship as part of Java 7, is an incrementally compacting collector that uses a snapshot-at-the-beginning (henceforth SATB) concurrent marking algorithm and stop-the-world compaction pauses to compact only parts of the heap in each pause. G1 allows the user to set pause time goals, and uses these goal inputs along with topology information collected during its mark phase in order to compact a limited amount of heap space in each pause, in an attempt to contain the amount of the heap references that need to be scanned during each pause.

Tene explains that, given its experimental state, it is still early to tell how G1 will fare with real applications. According to Tene, while G1 is intended to incrementally improve upon CMS’s handling of fragmentation, its compactions are still performed in complete stop-the-world conditions, and its ability to limit the length of incremental compaction pauses strongly depends on an application’s specific heap topology and object relationships. Applications with popular objects or popular heap portions will still experience long stop-the-world pauses when the entire heap needs to be scanned for references that need remapping, and those long pauses, while less frequent, will be no shorter than those experienced by the current CMS collector. As Tene puts it:

If a collector includes code that performs a full heap scan in stop-the-world conditions, that code is intended to run at some point, and application should expect to eventually experience such pauses.

Whilst G1 attempts to improve determinism, it cannot guarantee it. Tene explained:

It does let the user set pause time goals, but will only “try” to follow those goals. Even if OS scheduling was perfect, G1 would not guarantee determinism as its ability to contain individual compaction pauses is inherently sensitive to heap shape. Popular objects and (more importantly) popular heap regions (regions referred to from many other regions, but do not necessarily need to have popular individual objects) will cause G1 to eventually perform a full heap compaction in a single pause if they were to be compacted… Real application patterns (such as slowly churning LRU caches that get lots of hits) will exhibit such heap relationships in the vast majority of the heap, forcing G1 to perform what is effectively full compaction remap scans in a single pause…

A previous InfoQ article provides more of the technical details.

Conclusion

With the introduction of Zing, Azul has made pauseless garbage collection available in a pure software product on commodity hardware, making it more consumable and much easier to adopt. Pauseless garbage collection can:

1. Allow Java instances to make effective use of the abundant, cheap, commodity hardware capacities that are already available, and grow with future improvements to hardware.
2. Allow Architects and developers to make aggressive use of memory capacity in their designs, applying techniques such large in-memory, in-process caching, as well as complete in-memory representations to new problem sets.
3. Allow developers to avoid the fine tuning and re-tuning of current sensitive GC systems.

Azul提供了一个持续的有效的内存回收。更有效地利用硬件资源，鼓励开发者充分使用内存，避免GC的一些额外的优化设置。

上面说到了Java7推出的G1，稍后继续。。