JVM = interpreter + VM bindings
On Thu, 2005-13-01 at 18:18 -0500, Brian Thomas Sniffen wrote:
> "Grzegorz B. Prokopski" <gadek@debian.org> writes:
>
> > On Thu, 2005-13-01 at 15:58 -0500, Raul Miller wrote:
> >> On Thu, Jan 13, 2005 at 03:19:36PM -0500, Grzegorz B. Prokopski wrote:
> >>
> >> > http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL
> >> >
> >> > "However, when the interpreter is extended to provide "bindings" to
> >> > other facilities (often, but not necessarily, libraries), the
> >> ...
> >> > Do you understand that an interpreter for Java IS such an interpreter
> >> > that provides "bindings" to other facilities?
> >>
> >> But was Kaffe _extended_ to provide such bindings for Eclipse 3.0?
> >
> > This FAQ entry discusses 2 cases. One is when we have an interpreter,
> > that basically goes over the pseudo-code and purely "interprets" it
> > (an old BASIC interpreter would fit here). No Java VM/interpreter
> > _ever_ fits in this first, simple casse.
>
> I think you're making untenable conclusions based on your knowledge of
> accidents of implementation of Java VMs.
Sorry about that, now that the flaming part is hopefully over, I'll be
more than happy to give some more technically detailed informations.
I've just posted a hopefuly more meaningful sketch of what the
interconnections of program, java library, interpreter and its bindings
are.
> A Java bytecode interpreter is just an interpreter. The class
> libraries matter, and the libraries exposed through the JNI interface
> matter.
Sure they do. But it's hard to agree (after seeing how complicated
machinery a JVM is) that JVM is "just an interpreter". Actually the
interpreter part of SableVM (that is, where you take bytecodes one by
one and interpret them) is maybe 10-15% of it.
> > On the contrary. A Java Virtual Machine (Java interpreter) inevitably
> > has to provide such bindings to support Java specification. In other
> > words the interpreter itself has to be extended with a library that
> > provides these bindings to support Java specs. There's plenty of these
> > bindings required to exist in core java.lang.* classes.
>
> This confuses me, though. Can you provide an unambiguous example?
I'll do my best, and I'll try to show things that are not in any way
SableVM-specific.
Say a thread of your program acquired a lock (mutex, with a monitor in
C) and wants to wait on it, until it's signalled by another thread.
Your program has a VIRTUALCALL bytecode with reference to string
"java.lang.Object.wait()". Interpreter will see the bytecode, read
the string, make sure the object on which you're trying to invoke
wait() does actually implement it, then it will see that it's a
native method. It will therefore call a native (usually JNI) library,
which is part of the JVM itself to find a function ie.
Java_java_lang_Object_wait().
If a VM has moving garbage collector (SableVM, Sun, IBM, have) the
first thing this function will do is to call "resuming_java()" function
(this means "resuming java virtual machine internal code") to ensure
that ie. garbage collection will not happen, which would result in
objects being relocated.
It will then proceed by checking whether the current thread actually
owns the lock of the object on which it wants to wait() and will
instantiate and throw an exception if it doesn't.
Let's assume the excaption is to be thrown. Actually instantiating an
exception for the first time will make use of a class loading
facilities, which will have to go thru the hierarchy of class loaders.
Ie. it might be that an application's class loader will be asked first
to load the exeception class code, thus we'll be dumped back to the
interpreter and it will invoke some of the application code.
Then, after a class of the exception is loaded we will also have to
instantiate it, thus if it contained any "static initializers" - they
will need to be ran (again, we'll get back to the interpreter, which
might execute any amount of code static initializer called, even
including calling wait() or some other internal VM method again).
So we saw the following boundary crossings:
- Application is interpreted and calls java library
- java library is interpreted and calls VM library binding
- VM library method does some magic, possibly touching structures shared
between the VM library part and interpreter
- VM library calls interpreter again as a result of what happened
- interpreter executes application or library code
- this code can call the VM library again ...
- ...
The java library and the application of course can have their own
native libraries that are being called under way, but this is not
part of the discussion.
Now, the VM library is pretty much always statically linked (is part of)
to the "interpreter" part, because they often share many data
structures.
I have not shown an example, but even simple loading of the very first
class of an application which is about to run requires interaction with
VM library part. In such case VM library part would first ask class
loaders (pure java methods) about bytecodes to load, then would load
them into a shared location available also to the interpreter.
It is not possible to run an application, that has not been loaded,
and it is therefore to run any application w/o involving VM bindings.
VM bindings are necessary for JVM to execute programs, yet they are
not part of the interpreter itself.
Does it help?
Grzegorz B. Prokopski
--
Grzegorz B. Prokopski <gadek@sablevm.org>
SableVM - Free, LGPL'ed Java VM http://sablevm.org
Why SableVM ?!? http://sablevm.org/wiki/Features
Debian GNU/Linux - the Free OS http://www.debian.org
Reply to: