The machine code for an ideal Java CPU. Sun is working on silicon CPU for this set of op-codes. The multi-platform universal *.class files are the machine code for such an ideal machine due out in 1997. Mitsubishi has also announced one. JVMs can be interpreters, JITS, Hotspots or native code. See compiler for details. It is possible to write code for the JVM more or less directly with a JVM assembler. JVM also refers to the platform-specific program that can interpret JVM byte codes and execute them.

The JVM could be though of as just the java.exe program, a part of the JRE and JDK distributions.

I know of only four books that cover the JVM and the binary codes, the classfile format etc.

	recommend book⇒The Java Virtual Machine
		paperback
	ISBN10:	1-56592-194-1
	ISBN13:	978-1-56592-194-8
	publisher:	O’Reilly
	published:	1997-04
	by:	Joshua Engel
Known known as the goldfish bowl book because of its cover. The book is frustrating because it spends so much time with the irrelevant Jasmin assembler and its syntax. You are interested in generating byte codes directly, not assembler. It leaves out much you must discover by experiment looking at generated class files, such as whether offsets are signed or absolute, where the base is etc. In its next revision, it should set the Jasmin aside in an appendix, and include examples and more precise documentation on the binary formats. The book is still valuable because it gives a fair bit of background exposition you will not find in the vmspec itself. You would use this book to understand the VM, then the vmspec to actually write code that generated or modified class files.
amazon.ca amazon.com chapters.indigo.ca powells.com amazon.fr barnesandnoble.com amazon.de O’Reilly Safari amazon.co.uk

	recommend book⇒Programming For The Java Virtual Machine
		paperback
	ISBN10:	0-201-30972-6
	ISBN13:	978-0-201-30972-0
	publisher:	Addison-Wesley
	published:	1999-07-02
	by:	Joshua Engel
From the reviews it looks like it too gets hung up on a propietary assembler called Oolong. He does provide a code-generating class and spends one chapter on using it. I think the book would have been more useful if all the examples were in code-generator code, rather than an obscure dialect of assembler.
amazon.ca amazon.com chapters.indigo.ca powells.com amazon.fr barnesandnoble.com amazon.de amazon.co.uk

	recommend book⇒The Java Virtual Machine Specification
		paperback
	ISBN10:	0-201-43294-3
	ISBN13:	978-0-201-43294-7
	publisher:	Prentice Hall
	published:	1999-04-24
	by:	Tim Lindholm and Frank Yellin
Read the book on-line.
amazon.ca amazon.com chapters.indigo.ca powells.com amazon.fr barnesandnoble.com amazon.de amazon.co.uk

	recommend book⇒Inside The Java Virtual Machine
		paperback
	ISBN10:	0-07-135093-4
	ISBN13:	978-0-07-135093-8
	publisher:	McGraw-Hill
	published:	2000-01-06
	by:	Bill Venners
Covers Java 2 JVM internals. ISBN of first edition was 0-07-913248-0. See the blurb.
amazon.ca amazon.com chapters.indigo.ca powells.com amazon.fr barnesandnoble.com amazon.de amazon.co.uk

There are about 60 compilers that convert languages other than Java to JVM byte codes. They include: Tcl, BASIC, Scheme, Eiffel, COBOL, Ada, Python and Forth, as well as others less well known such as Pizza and Fiji. Robert Tolksdorf complied the list.

The standard JVM can only run one progam at a time. However Echidna lets you run many. It is a set of pure Java classes that will work with any JVM.

Roughly speaking, here is how a JVM works: the JVM has a heap that is managed by an automatic a garbage collector. On it are class objects, hunks of code (either in byte code format or natively compiled), ordinary objects and thread stacks. Each thread has its own 32-bit stack, typically about 1 MB of virtual RAM (quite a bit more overhead that most people would expect from a thread). The stack is broken into frames, once for each level of procedure call. A method can only "see" its frame, not those of its calling ancestors. The frame contains the parms passed to the method. Local references, local primitives and workspace are also stored on the stack.

The heap is typically broken into subheaps with various categories of objects collected together by size, age, class etc. For example, stack frames might typically be collected together since they are all the same length, and all large. This makes finding a suitable sized free slot faster, and avoids fragmentation. It also allows garbage collection to proceed incrementally on just one subheap at a time, rather than stopping everything to collect the entire heap.

If you want to peek under the covers and see in detail how the JVM works, you are out of luck. Sun does not disclose that. However. there are some other JVM implementations. The Kaffe VM is open source. There is Japhar, LGPLd, and Electrical Fire, which is a part of Mozilla.