It is.  I don't know a lot about the implementation of garbage
collection in Sun's reference implementation of the JVM... but modern
high-performance garbage collectors in general tend to split things up
in this way:

1. New objects that are smaller than some threshold size are allocated
in the "nursery".  New objects larger than that threshold size are
allocated in a "large object area" (skip to #4).

2. The nursery is generally copy-collected.  When an object survives the
nursery, it is moved to the next intermediate generation, which is
probably also copy-collected.

3. Eventually, after some number of copy-collected generations, there is
a mark/sweep generation which is sometimes called "oldspace".  Objects
live there for the remainder of their lives.

4. Large objects never enter any copy-collected generation.  They are
allocated either directly to oldspace, or to the large object area
(LOA).  In either case, they are not copy-collected at all.

So it's most likely a good deal more complicated than Benji said.  And
yes, it's all undefined, so there's likely to be a good deal of
variation in the implementation between virtual machines.

Well, you could implement GC as a stop-and-copy collector, or an incremental
collector, but you're guarenteed that liveness is the criteria for whether
or not something is considered garbage.  There are API utilities for
tweaking the GC that utilize this.  (e.g. WeakReference / StrongReference)