Jack said:
Finally the class is a not compiled code at all.
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 seems to be, and it is, the same source file, but without human
readable crap.
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.
JavaVM under Windows obviously uses the address space of itself and keeps
classes in form of instantinated objects (which are not related directly to
Java objects).
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.
All three kinds of binding are used in Java technology.
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.
--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.
Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
