计算机科学与技术Java垃圾收集器中英文对照外文翻译文献.docx

1、计算机科学与技术Java垃圾收集器中英文对照外文翻译文献中英文资料外文翻译文献原文：How a garbage collector works of Java LanguageIf you come from a programming language where allocating objects on the heap is expensive, you may naturally assume that Javas scheme of allocating everything (except primitives) on the heap is also expensive. Ho

2、wever, it turns out that the garbage collector can have a significant impact on increasing the speed of object creation. This might sound a bit odd at firstthat storage release affects storage allocationbut its the way some JVMs work, and it means that allocating storage for heap objects in Java can

3、 be nearly as fast as creating storage on the stack in other languages.For example, you can think of the C+ heap as a yard where each stakes out its own piece of turf object. This real estate can become abandoned sometime later and must be reused. In some JVMs, the Java heap is quite different; its

4、more like a conveyor belt that moves forward every time you allocate a new object. This means that object storage allocation is remarkably rapid. The “heap pointer” is simply moved forward into virgin territory, so its effectively the same as C+s stack allocation. (Of course, theres a little extra o

5、verhead for bookkeeping, but its nothing like searching for storage.) You might observe that the heap isnt in fact a conveyor belt, and if you treat it that way, youll start paging memorymoving it on and off disk, so that you can appear to have more memory than you actually do. Paging significantly

6、impacts performance. Eventually, after you create enough objects, youll run out of memory. The trick is that the garbage collector steps in, and while it collects the garbage it compacts all the objects in the heap so that youve effectively moved the “heap pointer” closer to the beginning of the con

7、veyor belt and farther away from a page fault. The garbage collector rearranges things and makes it possible for the high-speed, infinite-free-heap model to be used while allocating storage. To understand garbage collection in Java, its helpful learn how garbage-collection schemes work in other syst

8、ems. A simple but slow garbage-collection technique is called reference counting. This means that each object contains a reference counter, and every time a reference is attached to that object, the reference count is increased. Every time a reference goes out of scope or is set to null, the referen

9、ce count is decreased. Thus, managing reference counts is a small but constant overhead that happens throughout the lifetime of your program. The garbage collector moves through the entire list of objects, and when it finds one with a reference count of zero it releases that storage (however, refere

10、nce counting schemes often release an object as soon as the count goes to zero). The one drawback is that if objects circularly refer to each other they can have nonzero reference counts while still being garbage. Locating such self-referential groups requires significant extra work for the garbage

11、collector. Reference counting is commonly used to explain one kind of garbage collection, but it doesnt seem to be used in any JVM implementations. In faster schemes, garbage collection is not based on reference counting. Instead, it is based on the idea that any non-dead object must ultimately be t

12、raceable back to a reference that lives either on the stack or in static storage. The chain might go through several layers of objects. Thus, if you start in the stack and in the static storage area and walk through all the references, youll find all the live objects. For each reference that you fin

13、d, you must trace into the object that it points to and then follow all the references in that object, tracing into the objects they point to, etc., until youve moved through the entire Web that originated with the reference on the stack or in static storage. Each object that you move through must s

14、till be alive. Note that there is no problem with detached self-referential groupsthese are simply not found, and are therefore automatically garbage. In the approach described here, the JVM uses an adaptive garbage-collection scheme, and what it does with the live objects that it locates depends on

15、 the variant currently being used. One of these variants is stop-and-copy. This means thatfor reasons that will become apparentthe program is first stopped (this is not a background collection scheme). Then, each live object is copied from one heap to another, leaving behind all the garbage. In addi

16、tion, as the objects are copied into the new heap, they are packed end-to-end, thus compacting the new heap (and allowing new storage to simply be reeled off the end as previously described).Of course, when an object is moved from one place to another, all references that point at the object must be

17、 changed. The reference that goes from the heap or the static storage area to the object can be changed right away, but there can be other references pointing to this object Initialization & Cleanup that will be encountered later during the “walk.” These are fixed up as they are found (you could ima

18、gine a table that maps old addresses to new ones).There are two issues that make these so-called “copy collectors” inefficient. The first is the idea that you have two heaps and you slosh all the memory back and forth between these two separate heaps, maintaining twice as much memory as you actually

19、 need. Some JVMs deal with this by allocating the heap in chunks as needed and simply copying from one chunk to another.The second issue is the copying process itself. Once your program becomes stable, it might be generating little or no garbage. Despite that, a copy collector will still copy all th

20、e memory from one place to another, which is wasteful. To prevent this, some JVMs detect that no new garbage is being generated and switch to a different scheme (this is the “adaptive” part). This other scheme is called mark-and-sweep, and its what earlier versions of Suns JVM used all the time. For

21、 general use, mark-and-sweep is fairly slow, but when you know youre generating little or no garbage, its fast. Mark-and-sweep follows the same logic of starting from the stack and static storage, and tracing through all the references to find live objects. However, each time it finds a live object,

22、 that object is marked by setting a flag in it, but the object isnt collected yet. Only when the marking process is finished does the sweep occur. During the sweep, the dead objects are released. However, no copying happens, so if the collector chooses to compact a fragmented heap, it does so by shu

23、ffling objects around. “Stop-and-copy” refers to the idea that this type of garbage collection is not done in the background; Instead, the program is stopped while the garbage collection occurs. In the Sun literature youll find many references to garbage collection as a low-priority background proce

24、ss, but it turns out that the garbage collection was not implemented that way in earlier versions of the Sun JVM. Instead, the Sun garbage collector stopped the program when memory got low. Mark-and-sweep also requires that the program be stopped.As previously mentioned, in the JVM described here me

25、mory is allocated in big blocks. If you allocate a large object, it gets its own block. Strict stop-and-copy requires copying every live object from the source heap to a new heap before you can free the old one, which translates to lots of memory. With blocks, the garbage collection can typically co

26、py objects to dead blocks as it collects. Each block has a generation count to keep track of whether its alive. In the normal case, only the blocks created since the last garbage collection are compacted; all other blocks get their generation count bumped if they have been referenced from somewhere.

27、 This handles the normal case of lots of short-lived temporary objects. Periodically, a full sweep is madelarge objects are still not copied (they just get their generation count bumped), and blocks containing small objects are copied and compacted.The JVM monitors the efficiency of garbage collecti

28、on and if it becomes a waste of time because all objects are long-lived, then it switches to mark-and sweep. Similarly, the JVM keeps track of how successful mark-and-sweep is, and if the heap starts to become fragmented, it switches back to stop-and-copy. This is where the “adaptive” part comes in,

29、 so you end up with a mouthful: “Adaptive generational stop-and-copy mark-and sweep.”There are a number of additional speedups possible in a JVM. An especially important one involves the operation of the loader and what is called a just-in-time (JIT) compiler. A JIT compiler partially or fully conve

30、rts a program into native machine code so that it doesnt need to be interpreted by the JVM and thus runs much faster. When a class must be loaded (typically, the first time you want to create an object of that class), the .class file is located, and the byte codes for that class are brought into mem

31、ory. At this point, one approach is to simply JIT compile all the code, but this has two drawbacks: It takes a little more time, which, compounded throughout the life of the program, can add up; and it increases the size of the executable (byte codes are significantly more compact than expanded JIT

32、code), and this might cause paging, which definitely slows down a program. An alternative approach is lazy evaluation, which means that the code is not JIT compiled until necessary. Thus, code that never gets executed might never be JIT compiled. The Java Hotspot technologies in recent JDKs take a s

33、imilar approach by increasingly optimizing a piece of code each time it is executed, so the more the code is executed, the faster it gets.译文：Java垃圾收集器的工作方式 如果你学下过一种因为在堆里分配对象所以开销过大的编程语言，很自然你可能会假定 Java 在堆里为每一样东西（除了 primitives）分配内存资源的机制开销也会很大。不过，事实上垃圾收集器能够深刻影响对象的加速创建。 一开始听起来有些奇怪存贮空间的释放会影响存贮空间的分配，但是这的确是一些 JVMs 的工作方式，并且这意味着 J