a垃圾收集器中英文畢業(yè)論文-文庫(kù)吧
2025-06-13 07:47 本頁(yè)面
【正文】 e object that it points to and then follow all the references in that object, tracing into the objects they point to, etc., until you’ve moved through the entire Web that originated with the reference on the stack or in static storage. Each object that you move through must still be alive. Note that there is no problem with detached selfreferential groups—these are simply not found, and are therefore automatically garbage. In the approach described here, the JVM uses an adaptive garbagecollection scheme, and what it does with the live objects that it locates depends on the variant currently being used. One of these variants is stopandcopy. This means that—for reasons that will bee apparent—the 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 addition, as the objects are copied into the new heap, they are packed endtoend, thus pacting 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 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 amp。 Cleanup that will be encountered later during the “walk.” These are fixed up as they are found (you could imagine a table that maps old addresses to new ones).There are two issues that make these socalled “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 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 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. Markandsweep also requires that the program be stopped.As previously mentioned, in the JVM described here memory is allocated
規(guī)章制度相關(guān)推薦
鄂ICP備17016276號(hào)-1