Java News Brief        
                                                  February 2000 Issue                                        

Headlines: 
Java Technical Insight of the Month   -   Inside the Java Virtual Machine
     Visit  The Java News Brief Archive for past issues of the JNB.
OCI Education Center - Open Enrollment Schedule
             
                
Java Technical Insight of the Month 
What is the Java Virtual Machine?
By Ernest Rider, Senior Software Engineer, Object Computing, Inc.

The Java Virtual Machine (JVM), is the Sun Microsystems specification of a (emulated) virtual 32 bit processor, that directly supports the Java programming language.  The JVM executes operating system and hardware independent binary format bytecodes.  JVM's can currently execute 254 different types of "bytecodes" (virtual machine instructions).  Each bytecode is exactly one byte (8 bits). (bytecode 186 are unused)

What do bytecodes look like?

Well, they are all in binary format as we might expect.   Bytecodes exists to manipulate primitive types (byte, short, int, long, char, float, double, boolean, and JVM internal return address types) and reference types (Objects/Arrays).

All bytecodes look like this:

mnemonic <operand1>, <operand2>, ...... e.g. fadd

where mnemonic can be one of the pseudo codes in the table below:

Can other languages produce Java-byte code?

In Short.  Yes!

• Ada: http://www.appletmagic.com/index.html 

• bytecode Assembler: Jasmin, jas (http://www.sbktech.org/jas.html)

• Pascal: University. Vrije Universiteit, Amsterdam, Netherlands.

Does this mean we don't have to write in Java to get "bytecode" portability?   Well that's one for debate.   All I can say is that you get the wealth of a pure object orientated language in Java; some of the best minds fixing/enhancing the technology, and some really nice frameworks that other languages are struggling to match.  i.e. the Java Language embodies a design thought process,  that is conducive to good OOP Practices.

What makes up a JVM?

1.  A fetch, decode, execute module.
   
   This is really the heart of a JVM implementation.  It mimics a "real" machines fetch, decode and execute cycles.  The module will usually consist of a program counter PC (32 bits).   All other registers are not stipulated by the JVM specification, since many different architectures have different register capabilities that can be best exploited without adhering to a strict architecture.
       
   
2. A Stack per Thread. 
   
   The JVM Stack is a Last In-First Out (LIFO) stack that stores Frame's.  A Frame is a local block workspace, usually directly related to code that appears between "{"...."}" block specifiers.  In a REAL machine a frame is analogous to a a set of local block variables from the last Base Pointer BP to the current SP Stack Pointer.  During simulated multitasking (Single Processor) the fetch, decode, execute cycle the JVM can switch between stacks saving, and restoring the PC and any implementation registers, in some machines this is done preemptively (forced)  and in others each must yield to another.
   
   
3. Heap 
   
   The Java Heap is shared across all threads.  The heap contains dynamic Object references, including dynamically constructed Objects/Methods.   
   
   
4. Method area. 
   
   All compiled class/object methods are stored here. (Dynamic objects created at run time are stored in the heap and are exposed to the garbage collector.)
   
   
5. Constant pool. 
   
   Holds all the constants referenced by the system.  Some constants may be propagated through the bytecode in implementations.
   
   
6. Native method stack.
   
   A stack for which native methods can accept parameters from the JVM and return parameters to the JVM.  Some JVM's parse parameters using a 3rd party Native Language framework, such as RNI/COM in the Microsoft VM.
   
   
7. Garbage Collector.
   
   A Thread or Process that at determines whether Heap references have lost their Parent/Creator Object and are thus marked dirty for removal.   The Garbage collector is quite efficient despite the absence of a "C++" like "delete" operator.
   
   
8. bytecode Verifier.
   
   The bytecode verification process both complicated and sophisticated,  perhaps the most sophisticated part a a JVM implementation.     It addresses the concerns that bytecodes may do damage to a system by running amok on a given hardware architecture.   Sun's JVM Verifies bytecodes are well-formed before executing them.  This involves making sure all exceptions are caught,  no overflows etc.....      Some JVM's check while executing the bytecodes which can be expensive for performance.
   
   
9. Other Advanced Features.
   
   As Java Compiler technology improves, the separation of the JVM and the "real" machine gets narrower and narrower.   Just In Time (JIT) Compilation has become a key technology for improving JVM performance Ten fold.   A typical JIT will pre-optimise method bytecode's into native blocks ready to run on demand.  (Some JIT's use the native method stack, to invoke native methods.) 
   
   Implicit parallel computing support through the Java threading model is also making positive gains.   
   
   It is the authors opinion that through such research and development some JVM's may be able to operate as real time systems, despite the use of bytecode binaries.
   

Show us a program in bytecodes!

Example:

public class Person {

	String name = "Unknown";

	public void setName(String n) {
		name = n;
	}

	public String getName() {
		return(name);
	}

	public static void main(String args[]) {
		Person p = new Person();
		p.setName(args[0]);
		System.out.println("The name of the person entered was "+p.getName()+".");
	}
}

Using the command line java decompiler tool javap we can get the bytecode in pseudo ops ("-c") and the line numbers in the heap where they are stored ("-l").

C:\>javac Person.java
C:\>javap -c -l Person


Compiled from Person.java
public synchronized class Person extends java.lang.Object 
    /* ACC_SUPER bit set */
{
    java.lang.String name;
    public void setName(java.lang.String);
    public java.lang.String getName();
    public static void main(java.lang.String[]);
    public Person();
}

Method void setName(java.lang.String)
   0 aload_0
   1 aload_1
   2 putfield #14 -Field java.lang.String name-
   5 return

Line numbers for method void setName(java.lang.String)
   line 6: 0
   line 5: 5

Method java.lang.String getName()
   0 aload_0
   1 getfield #14 -Field java.lang.String name-
   4 areturn

Line numbers for method java.lang.String getName()
   line 10: 0

Method void main(java.lang.String[])
   0 new #4 -Class Person-
   3 dup
   4 invokespecial #9 -Method Person()-
   7 astore_1
   8 aload_1
   9 aload_0
  10 iconst_0
  11 aaload
  12 invokevirtual #17 -Method void setName(java.lang.String)-
  15 getstatic #15 -Field java.io.PrintStream out-
  18 new #7 -Class java.lang.StringBuffer-
  21 dup
  22 ldc #2 -String "The name of the person entered was "-
  24 invokespecial #11 -Method java.lang.StringBuffer(java.lang.String)-
  27 aload_1
  28 invokevirtual #13 -Method java.lang.String getName()-
  31 invokevirtual #12 -Method java.lang.StringBuffer append(java.lang.String)-
  34 ldc #1 -String "."-
  36 invokevirtual #12 -Method java.lang.StringBuffer append(java.lang.String)-
  39 invokevirtual #18 -Method java.lang.String toString()-
  42 invokevirtual #16 -Method void println(java.lang.String)-
  45 return

Line numbers for method void main(java.lang.String[])
   line 14: 0
   line 15: 8
   line 16: 15
   line 13: 45

Method Person()
   0 aload_0
   1 invokespecial #10 -Method java.lang.Object()-
   4 aload_0
   5 ldc #3 -String "Unknown"-
   7 putfield #14 -Field java.lang.String name-
  10 return

Line numbers for method Person()
   line 1: 0
   line 3: 4
   line 1: 10

How safe is my Java bytecode from Reverse Engineering?

Not very safe out-of-the-box.   Many products exist to make the job of decompiling exponentially harder (closer to near impossible) through obfuscation. (obfuscate.  To make so confused or opaque as to be difficult to perceive or understand)

An interesting article about finding similarities in bytecode can be found at http://glimpse.cs.arizona.edu/javadup.html
 

How to measure the performance of a JVM?

Just like testing "real" machine performance, JVM performance is an open-ended battle. Claim and counter claim over who's has the best JVM could go on forever.  This goes to show that computer people are very passionate people when it comes to issues such as performance.

"Performance means many things to many different applications."

So how do we meaningfully test performance?  Well first you must accept that the 90/10 rule applies in general, i.e. 90% of the time is spent in 10% of the code, for a given unit.  Then we must construct applications that typify our purpose or goal. Then we do some real time analysis.  (Using a Java Thread to time ourselves is not good enough, as JVM's are for the most part, non-real time.)  Fortunately the confusion over testing JVM performance has been confronted by the Java community.  In an effort to gain a useful comparison of JVM's a set of application performance benchmarks have been adopted (sometimes to suite the implementor).  It is very important that when using these tools the results have relevance to your needs. i.e. testing Thread performance may not give you great graphics.

Some useful ones:

The future of the JVM?

The future the Java Virtual Machine centers quite firmly - around increasing its performance on any given architecture. Researchers and developers will continue to peel away at its virtual'ness and add more and more real machine code while keeping the bytecode source intact.  Many different architectures, and frameworks will be added to aid industry in making open choices to technology.  Hardware architectures that are bytecode compatible are going to break performance ground earlier than software, but the holy grail is the hybrid interpreted/native compiler. This will continue to be developed and influence the ever increasing demand on performance software technology.
 

Interesting Articles on issues discussed.

• Parrallel Implementations: http://www.extreme.indiana.edu/~ajcbik/JAVAB/index.html
• Just in Time compilation: http://www.openjit.com.
• Caffiene mark. http://www.webfayre.com/pendragon/jpr/ http://www.webfayre.com/pendragon/jpr/jpr049705.html
• Fastest JVM: http://www.towerj.com/
• The JVM Specification: http://www.java.sun.com/docs/books/vmspec/index.html

OCI Education Center - Open Enrollment Schedule
Mesa, Arizona - St. Louis, Missouri

For more information or to register, email training.

Object Computing, Inc. is a Sun Authorized Java Center in St. Louis and a Member of the Object Management Group, OMG.  OCI specializes in distributed computing using object-oriented and web-enabled technologies and provides Consulting, Education, and Product Development services to clients nation-wide.  For more information contact us at 314-579-0066 or email info.

For employment opportunities at OCI call 1-888-962-4624 or email hr.

The Java News Brief is a monthly newsletter.  The purpose and intent of this publication is to advance Java, provide technical value, and to announce available OCI Java services.  If you would prefer to not receive this newsletter or would like to subscribe please email JNB and enter SUBSCRIBE or UNSUBSCRIBE within the Subject line.

Copyright (c) 2000.  Object Computing, Inc.   All rights reserved.   Java and all Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries.  Object Computing, Inc. is independent of Sun Microsystems, Inc.