diff options
Diffstat (limited to 'doc/html/docs/vmintegration.html')
| -rw-r--r-- | doc/html/docs/vmintegration.html | 227 |
1 files changed, 0 insertions, 227 deletions
diff --git a/doc/html/docs/vmintegration.html b/doc/html/docs/vmintegration.html deleted file mode 100644 index 55f77244b..000000000 --- a/doc/html/docs/vmintegration.html +++ /dev/null @@ -1,227 +0,0 @@ -<HTML> -<HEAD> -<!-- This HTML file has been created by texi2html 1.52 - from vmintegration.texinfo on 1 December 1998 --> - -<TITLE>GNU Classpath VM Integration Guide</TITLE> -</HEAD> -<BODY> -<H1>GNU Classpath VM Integration Guide</H1> -<ADDRESS>John Keiser</ADDRESS> -<P> -<P><HR><P> -<H1>Table of Contents</H1> -<UL> -<LI><A NAME="TOC1" HREF="vmintegration.html#SEC1">Introduction</A> -<LI><A NAME="TOC2" HREF="vmintegration.html#SEC2">Initialization</A> -<LI><A NAME="TOC3" HREF="vmintegration.html#SEC3">Classpath Hooks</A> -<LI><A NAME="TOC4" HREF="vmintegration.html#SEC4">Introduction</A> -</UL> -<P><HR><P> - -<P> -Copyright (C) 1998 Free Software Foundation, Inc. -<P> -Permission is granted to make and distribute verbatim copies of -this document provided the copyright notice and this permission notice -are preserved on all copies. - -</P> -<P> -Permission is granted to copy and distribute modified versions of this -document under the conditions for verbatim copying, provided that the -entire resulting derived work is distributed under the terms of a -permission notice identical to this one. - -</P> -<P> -Permission is granted to copy and distribute translations of this manual -into another language, under the above conditions for modified versions, -except that this permission notice may be stated in a translation -approved by the Free Software Foundation. - -</P> - - - -<H1><A NAME="SEC1" HREF="vmintegration.html#TOC1">Introduction</A></H1> - -<P> -The Classpath Project's ambition to be a 100% clean room implementation -of the standard Java class libraries cannot be fulfilled without some -level of integration with the Virtual Machine, the underlying machinery -that actually runs Java. - -</P> -<P> -There are several VMs out there, including -<A HREF="http://www.japhar.org">Japhar</A> and -<A HREF="http://www.kaffe.org">Kaffe</A>. Current integration efforts are -focused solely on Japhar, in order to get the basic interface down, and -all information contained in this document is gleaned from these -efforts. - -</P> - - - -<H1><A NAME="SEC2" HREF="vmintegration.html#TOC2">Initialization</A></H1> - -<P> -The order of initialization of classes is not so crucial to the Virtual -Machine, but is absolutely critical to Classpath itself. This section -shows the order in which classes should be loaded and initialized in -order for things to work properly. - -</P> -<P> -XXX Not ready yet. - -</P> - - - -<H1><A NAME="SEC3" HREF="vmintegration.html#TOC3">Classpath Hooks</A></H1> - -<P> -Several core classes must be implemented by the VM for Classpath to -work. These classes are java.lang.Runtime, java.lang.Thread, -java.lang.Class, java.lang.reflect.Constructor, -java.lang.reflect.Method, and java.lang.reflect.Field. - -</P> -<P> -You also need to implement some helper classes in java.lang that classes -from Classpath call out to to get certain VM-specific dirty work done: - -</P> - -<UL> -<LI>VMObject - -<LI>VMClassLoader - -<LI>VMSystem - -<LI>VMSecurityManager - -<LI>StackFrame - -<LI>StackTrace - -</UL> - -<P> -Some of the classes you implement for the VM will need to call back to -package-private methods in Classpath: - -</P> - -<UL> -<LI>java.lang.ThreadGroup.addThread(Thread) - -Call this method from Thread when a new Thread is created, to add it to -the group. - -<LI>java.lang.ThreadGroup.removeThread(Thread) - -Call this method from Thread when a Thread is stopped or destroyed. - -</UL> - - - -<H1><A NAME="SEC4" HREF="vmintegration.html#TOC4">Introduction</A></H1> - -<P> -VMs need to do some dirty work; there are some things in the VM that -unfortunately are dependent on the internal structure of various -classes. This is a guide to all of the things the VM itself needs to -know about classes. - -</P> - -<UL> -<LI>java.lang.Class - -You, the VM, get to create this Class, so you may define the internal -structure any way you wish. You probably have code somewhere to -translate your internal class structure into a Class object. That is -the only known place where this matters. Some VMs do not create the -Class object at the point where the class is defined; instead, they wait -until a Class object is actually used. - -<LI>array classes - -When you are creating an array class, you should set the ClassLoader of -the array class to the ClassLoader of its component type. Whenever you -add a class to a ClassLoader, you need to notify the ClassLoader and -add the new Class to its internal cache of classes. To do this, call -ClassLoader.addVMCreatedClass(Class). - -<LI>primordial class loader - -When the primordial class loader loads a class, it needs to tell -Classpath what it has done in order for security stuff to work right. -To do this, call the static method -ClassLoader.newPrimordialClass(Class). - -Even the first few core classes need to do this; in order to do it, -simply call this method <EM>after</EM> the initial class loading has been -done. No harm will come, as long as you follow the guidelines in the -see section <A HREF="vmintegration.html#SEC2">Initialization</A> section. - -<LI>throwing exceptions - -You do not need to fill in the stack trace or anything when throwing an -exception; this is all handled automatically with Classpath when the -constructor is called. - -<LI>top-level exception handler - -Exceptions take care of themselves in Classpath; all you need to do in -the top-level exception handler is call Throwable.printStackTrace(). - -XXX I think this was a bad design on my part. It takes up memory and -CPU cycles that do not need to be taken up for exceptions which are -simply caught. This portion of the VM interface will be changed so that -VMs must associate native stacktrace data with the Throwable itself or -even do some sort of lazy stacktrace information addition to the -Throwable, only copying stacktrace data as it is lost (as functions are -exited) to preserve memory and cycles. The usual case is the one where -an exception is caught. The top-level exception handler is, well, an -exception. - -<LI>Security and traces - -There will eventually be a feature in the 1.2 security that keeps the -AccessController from having to evaluate <EM>all</EM> of the -ProtectionDomains every time a security check is made. I think a common -case is a single method doing a lot of things that require security -checks. However, I don't want to bog down the method stack too much, so -this feature of the VM will have the AccessController for a thread -calling out to the VM to tell it how high it was on the stack when it -made the last security request. Every time the stack goes lower than -that number, the VM will decrement the number. The AccessController -will remember what the accumulated protection status was at every stack -level (an AccessControlContext) and use that aggregated information to -do the check. I am not sure, however, whether the savings are -substantial enough to outweigh the integer check and set after every -method call. I will investigate. - -<LI>java.lang.Thread - -You should not need to mess with the internal structure of this class, -even though threading is native to the VM, because there is typically -a native thread structure that you are using. The Thread object will, -of course, have to be linked to that native thread structure, and how -you do that is up to you. - -</UL> - -<P><HR><P> -This document was generated on 1 December 1998 using the -<A HREF="http://wwwinfo.cern.ch/dis/texi2html/">texi2html</A> -translator version 1.52.</P> -</BODY> -</HTML> |