"The difference between a DivideByZero and an ArithmeticException exception is that the DivideByZeroException is a checked exception and the ArithmeticException is unchecked. Because the ArithmeticException is unchecked, a method need not declare this exception in a throws clause even though it might throw it. Any exceptions that are subclasses of either Error or RuntimeException are unchecked. (ArithmeticException is a subclass of RuntimeException.) By catching ArithmeticException and then throwing DivideByZeroException, the remainder method forces its clients to deal with the possibility of a divide-by-zero exception, either by catching it or declaring DivideByZeroException in their own throws clauses. This is because checked exceptions, such as DivideByZeroException, thrown within a method must be either caught by the method or declared in the method's throws clause. Unchecked exceptions, such as ArithmeticException, need not be caught or declared in the throws clause."
"To coordinate shared data access among multiple threads, the Java virtual machine associates a lock with each object and class. A lock is like a privilege that only one thread can "possess" at any one time. If a thread wants to lock a particular object or class, it asks the JVM. At some point after the thread asks the JVM for a lock -- maybe very soon, maybe later, possibly never -- the JVM gives the lock to the thread. When the thread no longer needs the lock, it returns it to the JVM. If another thread has requested the same lock, the JVM passes the lock to that thread."
"When the Java virtual machine invokes a class method, it selects the method to invoke based on the type of the object reference, which is always known at compile-time. On the other hand, when the virtual machine invokes an instance method, it selects the method to invoke based on the actual class of the object, which may only be known at run time."
"Version 7.0 focuses on manageability, performance, and support for Intel's 32- and 64-bit architectures, although the 64-bit JVM is not yet available, said Bob Griswold, vice president and general manager of the Java runtime products group at BEA, in San Jose, Calif."
"The "virtual hardware" of the Java Virtual Machine can be divided into four basic parts: the registers, the stack, the garbage-collected heap, and the method area. These parts are abstract, just like the machine they compose, but they must exist in some form in every JVM implementation."
"Admittedly, the JVM alone isn't enough to compete with the entire .NET system. In particular, there is a missing "middle-layer" for porting other languages to the JVM (in the .NET system, this "middle-layer" is the IL). However, this problem has been solved on the JVM, too. Per Bothner, the same developer who started Jemacs, has generalized the intermediate representation (IR) used in GNU Kawa, the Java-based Scheme system. This work is making it possible for the Common Lisp and Emacs Lisp ports to come along nicely, and it is also the driving force behind my current work of porting Perl to the JVM. Thus, while the JVM by itself does not provide every piece needed to compete with .NET, such software does exist."
"Several vendors of specialized JVMs, such as application servers providers, have addressed this issue by creating multiprocess JVMs. These JVMs appear to run several Java processes within one system process. There is also a (free) pure Java library for multiprocessing JVMs, Echidna. If your interest is purely in using multiprocess JVMs, without actually needing to know the technology behind them, you need read no more of this article; instead, go to the Echidna site, download the library and documentation, and make your JVM multiprocess."
"Java application and component developers have a tendency to rely on a popular fiction known as the "vanilla VM configuration." The choice to rely on the VM to provide adequate, scalable runtime facilities for "real world" applications is often made out of lack of understanding, not expediency. This white paper demonstrates why Java developers need a non-trivial understanding of their runtime environment, the Java VM, by illustrating how some of the most common Java development assumptions can be harmful to a real-world Java application. As a concrete example, this paper addresses why relying on the system classpath is not a good idea in several different scenarios."
"The proposed extensions and modifications to the JVM have been prototyped as the Multi-Tasking Virtual Machine (MVM). Existing Java bytecodes can run unmodified, enjoying scalability benefits. New applications can take advantage of new abstractions and interfaces currently missing from the Java platform to accomplish a variety of systems programming tasks. "Across all the metrics of scalability we want to improve the well-being of Java programs," remarks Czajkowski. "We are scaling the Java platform and turning it into a complete operating environment, by adding various APIs and extensions so that anything you currently want to do in the domain of systems programming, you can do from within the language.""
"The Java virtual machine computes by performing operations on certain types of data. Both the data types and operations are strictly defined by the Java virtual machine specification. The data types can be divided into a set of primitive types and a reference type. Variables of the primitive types hold primitive values, and variables of the reference type hold reference values. Reference values refer to objects, but are not objects themselves. Primitive values, by contrast, do not refer to anything. They are the actual data themselves. You can see a graphical depiction of the Java virtual machine's families of data types in Figure 5-4."
"However, as Azul Systems' Gil Tene explains in this interview with Artima, the JVM has not been all that efficient when working with memory over a few gigabytes: Garbage collecting such large memory spaces can cause application pauses that may be unacceptable in interactive systems."
"The following table contains a list of the errata about which I know. Thanks to Marcus Rimmer, who reported a few of these items, and especially to Antoine Trux, who reported probably 80% of them or more. Antoine must have really consumed the book with great intensity to find so many typos and other errors. (He also must have liked it.)"
"To report errata or make comments or suggestion about Inside the Java Virtual Machine, please e-mail me at bv@artima.com. If possible, first look at the list of known errata before making your submission. I heartily welcome all feedback."
"The Fibonacci Forever applet, included below, demonstrates a Java Virtual Machine executing a sequence of bytecodes that generate the Fibonacci series. This applet accompanies Chapter 10, "Stack and Local Variable Operations, " of Inside the Java 2 Virtual Machine."
"The Hotspot VM is a collection of techniques, the most significant of which is called "adaptive optimization." In fact, this technique gives Hotspot its name."
"This article was first published under the name Under the Hood: The Lean, Mean Virtual Machine in JavaWorld, a division of Web Publishing, Inc., May 1996."
"The Circle of Squares applet, included below, demonstrates a Java virtual machine executing a sequence of bytecodes that perform floating-point arithmetic. This applet accompanies Chapter 14, "Floating Point Arithmetic," of Inside the Java 2 Virtual Machine."
"The Logical Results applet, included below, demonstrates a Java virtual machine executing a sequence of bytecodes. This applet accompanies Chapter 13, "Logic," of Inside the Java 2 Virtual Machine."
"The Saying Tomato applet, included below, demonstrates a Java virtual machine executing a sequence of bytecodes. This applet accompanies Chapter 16, "Control Flow," of Inside the Java 2 Virtual Machine."
"The Prime Time applet, included below, demonstrates a Java virtual machine executing a sequence of bytecodes that generates prime numbers. This applet accompanies Chapter 12, "Integer Arithmetic," of Inside the Java 2 Virtual Machine."
"On the eve of Sun's release of Java SE 6, Artima spoke with Coward about the future of dynamic language support on the JVM, about a new bytecode, invokedynamic, explicitly designed to support dynamic languages, about hot-swapping—the ability to change or add a method to a class at runtime—and about the goal of turning the JVM into an ideal target for dynamic language implementation."
"The Conversion Diversion applet, included below, demonstrates a Java virtual machine executing a sequence of bytecodes that performs type conversion. This applet accompanies Chapter 11, "Type Conversion," of Inside the Java 2 Virtual Machine."
"The Play Ball! Applet, included below, demonstrates a Java virtual machine executing a sequence of bytecodes. This applet accompanies Chapter 17, "Exceptions," of Inside the Java 2 Virtual Machine."
"The Getting Loaded applet, included below, simulates a Java virtual machine loading a class file. This applet accompanies Chapter 6, "The Java Class File," of Inside the Java 2 Virtual Machine."
"Here I recommend books that are related to the topics I cover in my book, Inside the Java 2 Virtual Machine. Each entry is linked to the page at Amazon.com where you can order the book online."
"I'd like to thank Michael O'Connell, the former Editor-in-Chief of JavaWorld, for giving me the opportunity to write about Java. I'd also like to thank Jill Steinberg, the current Editor-in-Chief, and the rest of the gang at JavaWorld for all their help with my original JavaWorld column, "Under the Hood.""
"The Java Virtual Machine Simulator Applets The Java Virtual Machine simulator applets all share a common package, COM.artima.jvmsim, that contains the bulk of the code that performs the simulation. For each individual applet, a class in the unnamed package serves as a "personality module" that customizes the behavior of the COM.artima.jvmsim code. All of these personality module classes descend from class COM.artima.jvmsim.JVMSimulator, which in turn descends from class java.applet.Applet. The personality module classes take as their name the title of the applet they represent. For example, the personality module for the Eternal Math applet is EternalMath.java."
"Java Report asked its contributors for feedback on what they believe to be some of the more exceptional products and tools they had encountered in 1998, and Inside the Java Virtual Machine was one of the chosen products. Here's what Antoine Trux, Java Report author, had to say about the book:"
"The Three-Dimensional Array applet, included below, demonstrates a Java virtual machine executing a sequence of bytecodes. This applet accompanies Chapter 15, "Objects and Arrays," of Inside the Java 2 Virtual Machine."
"The Hop Around applet, included below, demonstrates a Java virtual machine executing a sequence of bytecodes. This applet accompanies Chapter 18, "Finally Clauses," of Inside the Java 2 Virtual Machine."
"My primary goal in writing this book was to explain the Java virtual machine, and several core Java APIs closely related to the virtual machine, to Java programmers. Although the Java virtual machine incorporates technologies that had been tried and proven in other programming languages, prior to Java many of these technologies had not yet entered into common use. As a consequence, many programmers will be encountering these technologies for the first time as they begin to program in Java. Garbage collection, multi-threading, exception handling, dynamic extension--even the use of a virtual machine itself--may be new to many programmers. The aim of this book is to help programmers understand how all these things work, and in the process, to help them become more adept at Java programming."
"Welcome to Interactive Illustrations, a web companion to the book Inside the Java 2 Virtual Machine by Bill Venners. These web pages contain Java applets that interactively illustrate the concepts presented in the text of the book."
"The Slices of Pi applet, included below, demonstrates a Java virtual machine executing a sequence of bytecodes that calculates pi. This applet is described in Appendix D, "Slices of Pi: A Simulation of the Java Virtual Machine", of Inside the Java 2 Virtual Machine."
"The Eternal Math applet, included below, simulates a Java virtual machine executing a few bytecode instructions. This applet accompanies Chapter 5, "The Java Virtual Machine, " of Inside the Java 2 Virtual Machine."
"The second edition of Bill Venners' Inside the Java Virtual Machine, winner of a 1998 Java Report Writers Choice Award, is now available in bookstores. Inside the Java Virtual Machine explains Java's architecture and internals, and several Java APIs closely tied to the virtual machine, to Java programmers. Reading this book will help you gain a deeper understanding of Java technology, and in the process, help you become more effective at Java programming. This new edition is fully revised for Java 2, and includes much new material on a variety of JVM topics. You can order the book from Amazon by clicking on the image to the right."
"Bill Venners has been writing software professionally for 14 years. Based in Silicon Valley, he provides software consulting and training services through Artima Software Company. Since 1996, he has written over 40 articles about Java technology. His popular columns in JavaWorld magazine have covered Java internals, object-oriented design techniques, and Jini technology. He is also the author and webmaster of artima.com, an online resource for Java and Jini developers. He teaches in-house and public Java training seminars and frequently speaks on Java technology at software conferences around the world. You can reach him at bv@artima.com."
"Generational Garbage Collection The Java HotSpot VM uses a generational garbage collector, a well-known technique that exploits the following two observations:"
"The JVM is responsible for loading the classes in your application and classes from libraries that your application's classes use. Thus these could be classes loaded from WARs or EARs that you have deployed in Geronimo, JAR files included in your WAR or EAR, or classes from JARs loaded by the Geronimo container. The JVM can also choose to unload classes if the class has not been used for an extended period of time. This leads to several important statistics: how many classes have been loaded, how many have been unloaded, and how much time has been spent loading and unloading classes."
"Last month, we looked at the classic garbage collection techniques of reference counting, copying, mark-sweep, and mark-compact. Each of these approaches has advantages and disadvantages in certain situations. For example, copying does well when a large proportion of objects are garbage, but does poorly with many long-lived objects (copying them repeatedly). Conversely, mark-compact does quite well with long-lived objects (copying them only once), but not so well with many short-lived objects. The technique used by the 1.2 and later JVMs, called generational garbage collection, combines these two techniques to get the best of both worlds, and as a bonus provides very low object allocation overhead."
"Even though the generated classes specify JDK 5.0 and higher JVMs, that's not the end of the story. Developers have observed that some of the new features actually generate code that's fully compatible with older JVMs, while other features can be made compatible with some minor extensions to the standard libraries. One developer in particular, Toby Reyelts, decided to do something to get around the limitations of the JDK 5.0 compiler. The result is the open source Retroweaver project (see Resources). Retroweaver uses classworking techniques to modify the binary class representations generated by the JDK 5.0 compiler so the classes can be used with earlier JVMs."
"Short for reduced signaling, the rs parameter ensures that the JVM will ignore the signal induced by a user logging out. Prior to Java 1.3.0, the JVM did not react to such signals, so the problem did not exist."
"The first step in the process was to determine the cause of the sudden application slowdowns. First on our list of suspects was garbage collection. As we demonstrated in last month's column, the easiest way to determine if garbage collection and memory utilization issues are having a negative effect on your applications performance is to set the -verbose:gc JVM option and examine the log output. So we restarted the application with verbose garbage collection logging turned in, and patiently waited for the application's performance to fall off. Our patience paid off in the form of a very revealing gc log file."
"Jalape??s a virtual machine for Java servers written in the Java language. To be able to address the requirements of servers (performance and scalability in particular), Jalape??as designed "from scratch" to be as self-sufficient as possible. Jalape?? unique object model and memory layout allows a hardware null-pointer check as well as fast access to array elements, fields, and methods. Run-time services conventionally provided in native code are implemented primarily in Java. Java threads are multiplexed by virtual processors (implemented as operating system threads). A family of concurrent object allocators and parallel type-accurate garbage collectors is supported. Jalape?? interoperable compilers enable quasi preemptive thread switching and precise location of object references. Jalape?? dynamic optimizing compiler is designed to obtain high quality code for methods that are observed to be frequently executed or computationally intensive."
"Garbage Collector is one of the most important JVM components influencing JVM performance. General IBM JVM discussion (in IBM JVM Diagnostics Guides for JDK 1.3.1 and JDK 1.4.1) on GC and heap size tuning applies to IBM JVM on Linux, including Linux on POWER, with the exception of some IBM JVM on Linux specifics, discussed below."
"You have several options for tuning the garbage collection performance. These options exist as command line arguments on the java command. You can determine what options are available by issuing the java command as follows:"
"The history of refinements affecting Java performance is a complicated one, but on the upside it is also one of ever-increasing improvement. In this sidebar to the recent interview, IBM Distinguished Engineer Robert Berry walks us through the successive releases of the JDK and explains the key performance problems addressed in each release."
"Virtual Private Servers are the most advanced and affordable solution for anyone wanting to run their own server. They are used to partition a single physical server into many isolated virtual private servers. Each virtual private server looks and behaves exactly like a real networked server system, complete with its own set of init scripts, users, processes, and file systems. There is one downside to VPS: running Java on it. JVM only sees the computer as it is, 16Gigabytes of RAM and if you are attempting to start up an Application Server, JVM will happily attempt to reserve, say, 2 gigabytes and will not be able to do so in a 512 megabyte account. How can you get around this?"
"In Java 2 Micro Edition and the Kilobyte Virtual Machine , we'll delve into the specifics of actually getting your hands dirty writing a J2ME application for the Palm."
"Prior to Version 1.3, production releases of the Java 2 SDK, Standard Edition for the Solaris Operating Environment included a virtual machine1 implementation known as Exact VM (EVM). With the release of Java 2 SDK, Standard Edition 1.3, EVM is replaced by the Java HotSpot Server VM and the Java HotSpot Client VM. The Java HotSpot Client and Server VMs are designed to deliver a high level of performance for Java technology-based applications, in many cases a higher level of performance than these applications could achieve with EVM. However, as is true for most performance-enhancing tools, the performance of an application can also depend on other factors such as VM options specified at runtime."
