Not in any relevant sense.  Sun, obviously, decide /how/ any given release of
the JVM is implemented, but there's no public specification of the
implementation techniques used (how could there be -- if nothing else they need
the freedom to introduce new techniques as they are invented, or become
commercially feasible).

If you need /descriptions/ of how any particular version of any particular
vendor's JVM works, then you have several options:

Look at the source -- not always available, but sometimes it is.  Sun make
their source available.

Look for published papers by their JVM development team.  Sun also have
published a few, and some of them are listed somewhere on Sun's website:
   http://research.sun.com/java-topics/pubs/
IBM have published quite a lot too.  I don't have a link handy but searching
for
   "jikes research JVM"
seems to throw up some promising leads (Note that the implementation
technologies in the Jikes JVM are not necessarily used in their commercial
JVMs).

Look for patents applied for by the JVM development teams.

Look for the JVM development teams' blogs (if any).

Look for other material which /claims/ to be about how JVMs are implemented --
but take anything you find with two pinches of salt.  One pinch because stuff
changes over time, but out of date material hangs around on the Web and in
"folk law".  The other because not too many people really know what's going on
inside a high performance JVM except it's designers.

   -- chris

Unfortunately, no.  About 15 years ago, I used a C++ compiler for an
embedded processor that did not use vtables -- I know, because part of
the job involved examining the memory layout and writing assembly code
to interact with it.  The processor was the Z80, but I don't recall the
compiler or vendor.

It is simply my assumption that other C++ compilers may not use vtables,
either.  Perhaps my assumption is wrong.

The technique involved a single hidden field in each object to identify
its class.  Each virtual method signature foo in some class hierarchy
would cause the compiler to synthesize a _foo_dispatch function, which
did a conditional branch based on the contents of that hidden field.  
Calls to the member function would actually call _foo_dispatch, which
would jump to the appropriate code.

Although I can't guarantee this compiler did it, one could turn off
polymorphism beyond a certain superclass simply by changing the type
field.