for Performance Engineering phase: Can Vars be roots?

[Mark S. Miller <vlad!mark>]

An interesting possibility (best postponed till performance
engineering phase) is to have IntegerVar's and CheckedPtrVar's not be
Var's nor Tofu's.  Instead, they could be their own root class.  The
benefit of doing this is that then (hopefully) they could do without
vtables (having no virtual functions).  The problem is how we could
support their interaction with Stubble & with garbage collection if
they have no virtual functions.  I think this is solvable, but haven't
thought deeply about this.

I imagine a modular solution would involve making markInstances &
sendSelfTo into overloaded functions.  IntegerVar and CheckPtrVar
would provide their own overloadings.  Heaper would provide an
overloading that in turn invoked the markInstances & sendSelfTo
virtual functions of the Heaper.  (all very much analogous to Heaper
providing an overloading of operator<<, which in turn invokes the
printOn virtual member function of the Heaper)  The important point is
that Vars could always know their class at compile time, and so need
no run-time overhead.

I know that the above sketch probably has some big holes in it.  I'm
suggesting this now so we can chew on this in background mode for
awhile before needing to dive into it.  Normally, I'd be unconcerned
about an extra vtable--they're worth the overhead to save code
complexity.  Its just that for CheckPtrVar's and IntegerVar's
specifically, I think removing the vtable would be a big (and
worthwhile) savings.

What other subclasses of Var do we have?  If we can apply the above
technique to them as well, we probably should, and then retire the
class Var.