It is not Pentium native machine code. It is machine code for the Java
Virtual machine. It is the native machine code for PicoJava chips. See
http://mindprod.com/jgloss/picojava.html

It is not source with the comments removed, even though much of it is
intelligible to hex viewer. See http://mindprod.com/jasm.html

Try using Javah -c to disassemble some class files. You will see the
byte code resembles FORTH, a postfix, stack-based language.

see http://mindprod.com/jgloss/disassembler.html

There are a number of limits in the class file format which are not in
the running JVM itself.  For example inside the JVM you can have 64
bit references. The class file is the same. The size of the compiled
native code is not limited to 64K for a method. Inside the JVM, you
can have all the strings that will fit in the address space.

By everyone else's definition of the word "compile" Java bytecode is
definitely compiled.  Perhaps you meant to say that it is not native, in
which case you'd be right.  A second stage of the compiler (the JIT)
generally runs as the program is running to translate that bytecode into
machine code for the processor on which the code will run.

The class file contains a set of VM-level methods and fields and
constants, which mostly resemble the set written in the Java language.  
However, the *contents* of the methods (the bytecode) bears only some
resemblances to Java.  It does not radically depart from the memory
model, but it throws out decisions about choice of control flow
constructs, block scope, order of operation rules, variable names, etc.

I'm not at all sure what you mean by "instantiated objects", which
you've said a couple of times.  I get the feeling from context that you
don't mean the same thing as most other people would when they say the
same thing.

All major Java virtual machines for conventional CPUs with MMUs reside
in a single address space, and load all of their code into that address
space.  I am not aware of any JVM that makes use of shared memory or
other IPC between separate processes (except insofar as pre-NPTL
versions of Linux tend to treat threads as multiple processes that share
everything).  There will exist in that address space one or more copies
of the bytecode: one as the bytecode itself, and a natively compiled
(JITed) versions; and potentially other JITed versions if the JIT
compiler determines that it's worth recompiling for special cases to
improve efficiency.

I don't know what distinction you're making between the three kinds of
binding.  In fact, you seem to have made a habit of assuming that
everyone shares your understanding of terminology.  In reality,
terminology differs from context to context; and textbook authors,
technical presenters, etc. often make it up on the fly to express the
distinctions that happen to be useful for them, right now.

This might help.  There are the following different bytecodes used in
the JVM to invoke methods:

   invokevirtual
   invokestatic
   invokespecial
   invokeinterface

(and the special cases: invokevirtual_quick, invokenonvirtual_quick,
invokesuper_quick, invokestatic_quick, invokeinterface_quick,
invokevirtualobject_quick, invokevirtual_quick_w)

Ignoring the special cases, the four invoke opcodes could be said to
correspond loosely to kinds of method binding, but I don't think that
they correspond directly to the terms you've used.  The most dynamic is
invokeinterface.  Two of the four -- virtual and interface -- are
polymorphic, whereas the other two -- special and static -- can be
completely resolved earlier in the class loading and JIT process.  The
only difference between special and static is whether to pass an
implicit this pointer, which is irrelevant to a discussion of method
binding.

Note that the term "compile-time" is problematic when discussing the
JVM, since there are two compilers involved -- the source compiler, and
the JIT compiler.  No methods are ever completely bound by the source
compiler; it always embed the names of methods into the class file and
leaves the runtime class loader to resolve them.  The JIT compiler will
typically completely resolve an invokespecial or invokestatic all the
way to a direct memory address for a jump or jsr instruction.  It will
resolve invokevirtual to a simple indirect jump (as in, jump to
[obj_base + offset]).  Unless it has some specialized global knowledge
of the application, the JIT will generate table lookup code for an
invokeinterface instruction.

All of this, of course, is typical implementation.  The JVM is free to
choose any alternate implementation, so long as the observed behavior is
the same.

Now, I'm confused as to why this would have any impact on security...
but there it is, anyway.