计算机专业外文翻译--java垃圾收集器的工作方式(编辑修改稿)

计算机专业外文翻译--java垃圾收集器的工作方式(编辑修改稿)内容摘要：

ying process itself. Once your program bees stable, it might be generating little or no garbage. Despite that, a copy collector will still copy all the 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 markandsweep, and it’s what earlier versions of Sun’s JVM used all the time. For general use, markandsweep is fairly slow, but when you know you’re generating little or no garbage, it’s fast. Markandsweep 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, that object is marked by setting a flag in it, but the object isn’t 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 pact a fragmented heap, it does so by shuffling objects around. “Stopandcopy” 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 you’ll find many references to garbage collection as a lowpriority background process, 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. 本科生毕业设计（论文） 第 4 页 Markandsweep also requires that the program be stopped. As previously mentioned, in the JVM described here memory is allocated in big blocks. If you allocate a large object, it gets its own block. Strict stopandcopy 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 copy objects to dead blocks as it collects. Each block has a generation count to keep track of whether it’s alive. In the normal case, only the blocks created since the last garbage collection are pacted。 all other blocks get their generation count bumped if they have been referenced from somewhere. This handles the normal case of lots of shortlived temporary objects. Periodically, a full sweep is made—large objects are still not copied (they just get their generation count bumped), and blocks containing small objects are copied and pacted. The JVM monitors the efficiency of garbage collection and if it bees a waste of time because all objects are longlived, then it switches to markand sweep. Similarly, the JVM keeps track of how successful markandsweep is, and if the heap starts to bee fragmented, it switches back to stopandcopy. This is where。