appendixe.html

java 是一个很好的网络开发环境。由于它是通过解释的方法

attached to an object the reference count is increased. Every time a handle goes
out of scope or is set to <B>null</B>, the reference 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. The one drawback is that if objects circularly refer to
each other they can have non-zero reference counts while still being garbage.
Locating such self-referential groups requires significant extra work for the
garbage collector. Reference counting is commonly used to explain one kind of
garbage collection but it doesn&#8217;t seem to be used in any JVM
implementations.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">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 traceable back to a handle 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 the static
storage area and walk through all the handles you&#8217;ll find all the live
objects. For each handle that you find, you must trace into the object that it
points to and then follow all the handles in <I>that</I> object, tracing into
the objects they point to, etc., until you&#8217;ve moved through the entire web
that originated with the handle 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 self-referential groups &#8211; these are simply not found, and are
therefore automatically garbage.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">In the approach described here, the
JVM uses an <I>adaptive </I>garbage-collection scheme, and what it does with the
live objects that it locates depends on the variant currently being used. One of
these variants is <I>stop-and-copy</I>. This means that, for reasons that will
become apparent, the program is first stopped (this is not a background
collection scheme). Then, each live object that is found 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 end-to-end, thus compacting the new
heap (and allowing new storage to simply be reeled off the end as previously
described).</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">Of course, when an object is moved
from one place to another, all handles that point at (reference) that object
must be changed. The handle that comes from tracing to the object from the heap
or the static storage area can be changed right away, but there can be other
handles pointing to this object that will be encountered later during the
&#8220;walk.&#8221; These are fixed up as they are found (you could imagine a
hash table mapping old addresses to new ones).</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">There are two issues that make 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.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">The second issue is the copying.
Once your program becomes 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
&#8220;adaptive&#8221; part). This other scheme is called <I>mark and sweep</I>,
and it&#8217;s what Sun&#8217;s JVM uses all the time. For general use mark and
sweep is fairly slow, but when you know you&#8217;re generating little or no
garbage it&#8217;s fast.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">Mark and sweep follows the same
logic of starting from the stack and static storage and tracing through all the
handles 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&#8217;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 compact a fragmented heap it does so by shuffling objects
around.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">The &#8220;stop-and-copy&#8221;
refers to the idea that this type of garbage collection is <I>not</I> done in
the background; instead, the program is stopped while the GC occurs. In the Sun
literature you&#8217;ll find many references to garbage collection as a
low-priority background process, but it turns out that this was a theoretical
experiment that didn&#8217;t work out. In practice, the Sun garbage collector is
run when memory gets low. In addition, mark-and-sweep requires that the program
be stopped.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">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 stop-and-copy requires copying every live
object from the source heap to a new heap before you could free the old one,
which translates to lots of memory. With blocks, the GC can typically use dead
blocks to copy objects to as it collects. Each block has a <I>generation
count</I> to keep track of whether it&#8217;s alive. In the normal case, only
the blocks created since the last GC are compacted; all other blocks get their
generation count bumped if they have been referenced from somewhere. This
handles the normal case of lots of short-lived temporary objects. Periodically,
a full sweep is made &#8211; large objects are still not copied (just get their
generation count bumped) and blocks containing small objects are copied and
compacted. The JVM monitors the efficiency of GC 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 &#8220;adaptive&#8221; part comes in, so you end up with a mouthful:
&#8220;adaptive generational stop-and-copy
mark-and-sweep.&#8221;</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">There are a number of additional
speedups possible in a JVM. An especially important one involves the operation
of the loader and Just-In-Time (JIT) compiler. When a class must be loaded
(typically, the first time you want to create an object of that class), the
<B>.class</B> file is located and the byte codes for that class are brought into
memory. At this point, one approach is to simply JIT 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 code) and this
might cause paging, which definitely slows down a program. An alternative
approach is <I>lazy evaluation,</I> which means that the code is not JIT
compiled until necessary. Thus, code that never gets executed might never get
JIT compiled.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">Because JVMs are external to
browsers, you might expect that you could benefit from the speedups of some JVMs
while using any browser. Unfortunately, JVMs don&#8217;t currently interoperate
with different browsers. To get the benefits of a particular JVM, you must
either use the browser with that JVM built in or run standalone Java
applications.</FONT><BR></P></DIV>
<DIV ALIGN="CENTER">
    <FONT FACE="Verdana" size = "-1">
     [ <a href="AppendixD.html">Previous Chapter</a> ] 
    [ <a href="SimpleContents.html">Short TOC</a> ] 
    [ <a href="Contents.html">Table of Contents</a> ] 
    [ <a href="DocIndex.html">Index</a> ]
     [ <a href="AppendixF.html">Next Chapter</a> ] 
    </FONT>
    <BR>
 Last Update:02/04/2000</P></DIV>

</BODY>

</HTML>