Why are there two of everything?

You might have noticed that in addition to the

Tiger source snapshots, we have just posted a

Mustang source snapshot under the

Java Research license.

So now we have two code lines being actively worked on:
we continue to find bugs in Tiger and fix them in update releases,
and we have on-going development in Mustang.
That's bound to be confusing.
I'm a HotSpot virtual machine engineer so I'm used to having
two (or more) code lines in progress. But if you are going
to rummage around in the HotSpot virtual machine sources
(under hotspot/src), I'd like to explain why we seem to have
two of a lot of things. I'll gradually work my way down through
the layers of this particular onion.

• We have to ship releases.
  We have Tiger and Mustang (and all the other releases)
  because we want to get stuff out into the hands of our users.
  But we're never really "done", so development is continuous
  while releases are periodic. What you see by looking
  at the current Tiger and Mustang source snapshots is that early
  in a release (Mustang) there isn't really that much difference
  between from the previous release (Tiger). But new development
  stopped on Tiger months ago. At any given time, we have (at
  least) two releases in progress, one in active development,
  the other(s) for bug fix updates.
• Backward compatibility.
  Once you get into the sources for the virtual machine,
  you'll sometimes find that we often have two implementations
  of things. One reason for this is because we think backward
  compatibility is really important. While we are working
  on some new thing, we have to keep the old thing working,
  and the easiest way to do that is to keep the old thing
  around. While browsing through the sources, you'll find
  a lot of code guarded by command-line switches you probably
  didn't know about. (Look at all those command line switches
  in hotspot/src/share/runtime/globals.hpp!) Those are there
  so we can do A-B comparisons for functionality, conformance,
  performance, footprint, etc. Only when an new implementation
  shows itself to be compatible and substantially better than
  the old one do we throw the switch to use the new one. And
  we usually leave the switch around for a release or two
  in case someone wants to revert to the old behavior.
• Dessert topping or floor wax.
  One of the problems with being a successful Java virtual
  machine is that people want to use you for everything, even
  things you didn't exactly anticipate. While the Java platform
  might have burst on the scene as a way of executing content
  for small applets in web browsers (and people still use it for
  that), people now also use it for running gigantic high-throughput
  applications on big multiprocessors. Of course, we want to
  make everyone happy, but that often means having alternate
  implementations inside the virtual machine. You can see this
  in the choice of the client versus server runtime compiler:
  the client runtime compiler gives good startup and modest
  performance, while the server runtime compiler is not as fast
  to start up, but the code it generates runs significantly faster.
  You can't use them both at the same time (yet), but if you are
  looking around the code base, you'll find both runtime compilers
  in there.
• One size does not fit all.
  In that same style of offering different qualities of service,
  we offer something like 3 different garbage collection algorithms.
  The concurrent mark sweep algorithm provides lower pause times at
  some cost in performance, while the parallel collector offers
  better performance with occasional longer pauses. We're not going
  make that choice for our users. If you go looking for "the
  garbage collector", you'll be disappointed (or maybe pleasantly
  surprised) to find at least three of them in there.
• We learn, but slowly.
  The HotSpot Java virtual machine is a work in progress.
  Ideas that we had a while ago might have been appropriate for
  then, but things change. So the source base changes too. We
  learn things about the interactions of the different parts of
  the virtual machine (basically: compiler(s), garbage collector(s),
  and runtime system) and we try to clean up the code. In some
  parts of the virtual machine, that means changing the interfaces,
  but our desire not to be disruptive means we often leave the
  old interface and implementation in place for a release or two.
  For example, the older garbage collectors use a "generation
  framework" that is extremely flexible, but has some overhead.
  The newest collector uses a less flexible interface that is
  more efficient. We won't gratuitously convert the older
  collectors (we'd risk breaking things, for no benefit to you,
  our customers), so you'll find both programming styles in there
  if you look.
• It depends on your point of view.
  Sometimes you'll be prowling through the source and come
  across things that look to be two of the same thing. For example,
  hotspot/src/share/oops/oopsHierarchy.hpp shows what appear to be
  similar hierarchies for oops and klasses.
  But those are not alternate implementations, or us evolving the
  interface, or anything like that. They are two faces of
  the virtual machine's view of the data structures used to
  represent Java objects (and a few VM internal data structures).
  Simplifying somewhat: an oop is the Java reference to an object,
  whereas the klass is the way we manipulate that object from the
  C++ code inside the virtual machine. That's an example of where
  you have to be able to hold both ideas in your head at the same
  time, instead of looking at only the one you think you are
  interested in.

The HotSpot virtual machine is a collection of engineering
tradeoffs and compromises. As such you will often find more
than one way of doing things when you look through the sources.
I hope I've clarified some of the reasons for that. If not,
ask questions and I'll try to come up with answers.