((cite: hotspot/src/share/vm/opto/optoreg.hpp))
    //------------------------------OptoReg----------------------------------------
    // We eventually need Registers for the Real World.  Registers are essentially
    // non-SSA names.  A Register is represented as a number.  Non-regular values
    // (e.g., Control, Memory, I/O) use the Special register.  The actual machine
    // registers (as described in the ADL file for a machine) start at zero.
    // Stack-slots (spill locations) start at the nest Chunk past the last machine
    // register.
    //
    // Note that stack spill-slots are treated as a very large register set.
    // They have all the correct properties for a Register: not aliased (unique
    // named).  There is some simple mapping from a stack-slot register number
    // to the actual location on the stack; this mapping depends on the calling
    // conventions and is described in the ADL.
    //
    // Note that Name is not enum. C++ standard defines that the range of enum
    // is the range of smallest bit-field that can represent all enumerators
    // declared in the enum. The result of assigning a value to enum is undefined
    // if the value is outside the enumeration's valid range. OptoReg::Name is
    // typedef'ed as int, because it needs to be able to represent spill-slots.
    //
    class OptoReg VALUE_OBJ_CLASS_SPEC {

    ((cite: hotspot/src/share/vm/opto/optoreg.hpp))
      typedef int Name;

    ((cite: hotspot/src/share/vm/opto/optoreg.hpp))
    //---------------------------OptoRegPair-------------------------------------------
    // Pairs of 32-bit registers for the allocator.
    // This is a very similar class to VMRegPair. C2 only interfaces with VMRegPair
    // via the calling convention code which is shared between the compilers.
    // Since C2 uses OptoRegs for register allocation it is more efficient to use
    // VMRegPair internally for nodes that can contain a pair of OptoRegs rather
    // than use VMRegPair and continually be converting back and forth. So normally
    // C2 will take in a VMRegPair from the calling convention code and immediately
    // convert them to an OptoRegPair and stay in the OptoReg world. The only over
    // conversion between OptoRegs and VMRegs is for debug info and oopMaps. This
    // is not a high bandwidth spot and so it is not an issue.
    // Note that onde other consequence of staying in the OptoReg world with OptoRegPairs
    // is that there are "physical" OptoRegs that are not representable in the VMReg
    // world, notably flags. [ But by design there is "space" in the VMReg world
    // for such registers they just may not be concrete ]. So if we were to use VMRegPair
    // then the VMReg world would have to have a representation for these registers
    // so that a OptoReg->VMReg->OptoReg would reproduce ther original OptoReg. As it
    // stands if you convert a flag (condition code) to a VMReg you will get VMRegImpl::Bad
    // and converting that will return OptoReg::Bad losing the identity of the OptoReg.

    class OptoRegPair {