OSDN Git Service

2013.10.24
[uclinux-h8/uClinux-dist.git] / lib / classpath / doc / cp-vmintegration.texinfo
1 \input texinfo @c -*-texinfo-*-
2
3 @c %**start of header
4 @setfilename cp-vmintegration.info
5 @settitle GNU Classpath VM Integration Guide
6 @c %**end of header
7
8 @setchapternewpage off
9
10 @ifinfo
11 This file contains important information you will need to know if you
12 are going to write an interface between GNU Classpath and a Virtual
13 Machine.
14
15 Copyright (C) 1998-2002, 2004, 2005, 2006, 2007 Free Software Foundation, Inc.
16
17 @ifnotplaintext
18 @dircategory GNU Libraries
19 @direntry
20 * VM Integration: (cp-vmintegration).  GNU Classpath VM Integration Guide
21 @end direntry
22 @end ifnotplaintext
23 @end ifinfo
24
25 @titlepage
26 @title GNU Classpath VM Integration Guide
27 @author John Keiser
28 @author C. Brian Jones
29 @author Mark Wielaard
30
31 @page
32 @vskip 0pt plus 1filll
33 Copyright @copyright{} 1998-2002 Free Software Foundation, Inc.
34 @sp 2
35 Permission is granted to make and distribute verbatim copies of
36 this document provided the copyright notice and this permission notice
37 are preserved on all copies.
38
39 Permission is granted to copy and distribute modified versions of this
40 document under the conditions for verbatim copying, provided that the
41 entire resulting derived work is distributed under the terms of a
42 permission notice identical to this one.
43
44 Permission is granted to copy and distribute translations of this manual
45 into another language, under the above conditions for modified versions,
46 except that this permission notice may be stated in a translation
47 approved by the Free Software Foundation.
48
49 @end titlepage
50
51 @ifinfo
52 @node Top, Introduction, (dir), (dir)
53 @top GNU Classpath Hacker's Guide
54
55 This file contains important information you will need to know if you
56 are going to write an interface between GNU Classpath and a Virtual
57 Machine.
58
59 This document is incomplete, as we are still in alpha with the interface.
60
61 @end ifinfo
62
63 @menu
64 * Introduction::                An introduction to the Classpath project
65 * Initialization::              Initializing the classes
66 * Classpath Hooks::             Hooks from Classpath to the VM
67 * VM Hooks::                    Hooks from the underlying VM to Classpath
68 * JNI Implementation::          Hooking the VM to jni.h
69 * JVMTI Implementation::        Hooking the VM to jvmti.h
70 * Miscellaneous VM Requirements::  
71 @end menu
72
73 @node Introduction, Initialization, Top, Top
74 @comment node-name, next, previous, up
75 @chapter Introduction
76
77 The Classpath Project's ambition to be a 100% clean room implementation
78 of the standard Java class libraries cannot be fulfilled without some
79 level of integration with the Virtual Machine, the underlying machinery
80 that actually runs Java.
81
82 There are several VMs out there, here is a small list.
83
84 @itemize @bullet
85 @item @uref{http://www.hungry.com/old-hungry/products/japhar/,Japhar}
86 Japhar was the first VM to use GNU Classpath.  Today you can see that
87 sort of relationship in the source tree which denotes several Japhar
88 specific files as a reference implementation of those pieces.  This VM
89 has been primarily tested against Linux and lacks garbage collections, a
90 JIT, and suffers recently from slow development.
91
92 @item @uref{http://www.intel.com/research/mrl/orp/,Intel's Open Runtime Platform}
93 Intel surprised us not long ago with the release of this rather advanced
94 VM that uses GNU Classpath for a set of class libraries and works on
95 Linux and Windows 2000.  As of June, 2004, it does not appear that ORP
96 is under active development.
97
98 @item @uref{http://www.sablevm.org/,SableVM}
99 SableVM is a robust, extremely portable, efficient, and
100 specifications-compliant Java Virtual Machine that aims to be easy to
101 maintain and to extend. It features a state-of-the-art, efficient
102 interpreter engine. Its source code is very accessible and easy to
103 understand, and has many robustness features that have been the object
104 of careful design.
105
106 @item @uref{http://www.kaffe.org,Kaffe}
107 Kaffe is an advanced VM and together with its own class libraries
108 provides a Java 1.1 compatible environment.
109
110 @item @uref{http://www.mozilla.org/projects/ef,Electrical Fire}
111 The Electrical File VM continues to be listed as a Mozilla project
112 though development has been somewhat quiet.  A number of concepts from
113 EF were expected at one point to be rolled into Japhar, but that
114 development has not occurred as of yet.
115
116 @item @uref{http://latte.snu.ac.kr/,LaTTe}
117 This VM project so far supports only Sun UltraSparc processors using the
118 proprietary Solaris 2.5.1 or higher operating system.  LaTTe was derived
119 from Kaffe but claims a number of improvements.
120
121 @item @uref{http://gcc.gnu.org/java/,GNU Compiler for Java (GCJ)}
122 This is a portable, optimizing, ahead-of-time compiler for the Java
123 Programming Language. It can compile Java source code directly to native
124 machine code, Java source code to Java bytecode (class files), and Java
125 bytecode to native machine code. Compiled applications are linked with the
126 GCJ runtime, libgcj which is based on the GNU Classpath code, which provides
127 the core class libraries, a garbage collector, and a bytecode interpreter.
128 libgcj can dynamically load and interpret class files, resulting in mixed
129 compiled/interpreted applications.
130 GCJ is part of the GNU Compiler Collection (@uref{http://gcc.gnu.org/,GCC}).
131 On March 6 2000 the libgcj and GNU Classpath projects were officially merged
132 and there is active work on merging all the classes between the projects.
133 Licensed under GPL+exception, just as GNU Classpath is.
134
135 @item @uref{http://kissme.sourceforge.net/,Kissme}
136 This is a free Java Virtual Machine that is being developed on GNU/Linux
137 and can run console Java applications.  Kissme also provides support for
138 orthogonally persistent Java.
139 @c I don't know what ``orthogonally persistent Java'' is, and I bet
140 @c there are other people don't know either. -- Steve Augart, 4 June 2004
141
142 @item @uref{http://jamvm.sourceforge.net/,JamVM}
143 A simple, small bytecode interpreter that works out-of-the-box with
144 pure GNU Classpath; it is emerging as the preferred platform for
145 quickly testing a new build of GNU Classpath.  Licensed under the GPL.
146
147 @item @uref{http://jikesrvm.sourceforge.net/,Jikes RVM}
148 A free runtime environment for Java, written in Java.  Works
149 out-of-the-box with pure GNU Classpath.  Features an optimizing JIT.
150 Runs on the x86 and PowerPC architectures, on the AIX, Linux, and Mac
151 OS/X operating systems.  Licensed under the CPL (Common Public
152 License).  Extensively documented.  Actively developed as of June,
153 2004.
154
155 @end itemize
156
157 In the past integration efforts were focused mainly on Japhar with an eye
158 towards getting Electrical Fire to work.  Most information contained in
159 this document is gleaned from these efforts. Recently more work has been
160 done on getting gcj, orp and kissme to work out of the box with GNU Classpath
161 but there is much to do before that becomes a reality.
162
163
164 @node Initialization, Classpath Hooks, Introduction, Top
165 @comment node-name, next, previous, up
166 @chapter Initialization
167
168 The order of initialization, as far as I can tell, doesn't matter just
169 yet.  However, when we move to 1.2 support, it probably will matter, so
170 we'll have a note in here at that time.
171
172 The initialization order is currently documented in the
173 @file{Runtime.java} source file.
174
175 @node Classpath Hooks, VM Hooks, Initialization, Top
176 @comment node-name, next, previous, up
177 @chapter Classpath Hooks
178
179 The primary method of interaction between Classpath and the VM is via
180 the helper classes, which are named after the relevant core library
181 class, but include an additional `VM' prefix.  The library classes from
182 Classpath call out to these to get certain VM-specific dirty work done.
183 A reference copy of each VM class exists.  The majority consist of a
184 series of static methods, some of which are simply declared
185 @code{native}, and some which provide a default implementation.  VMs may
186 either use these as is, or create their own local variations.  When
187 using the default implementations, the VM is responsible for
188 implementing any of the code marked as @code{native} which corresponds
189 to functionality they wish their VM to provide.  When using their own
190 versions of the classes, VM implementors may choose to change the mix of
191 native and non-native methods from that below, so as to best suit their
192 implementation.
193
194 @menu
195 * java.lang::
196 * gnu.classpath::
197 * java.util::
198 * java.io::
199 * java.security::
200 * java.net::
201 * java.nio::
202 * java.nio.channels::
203 * gnu.java.nio::
204 * java.lang.reflect::
205 * gnu.java.lang::
206 * gnu.java.lang.management::
207 * java.lang.management::
208 * Classpath Callbacks::
209 @end menu
210
211 @node java.lang, gnu.classpath, Classpath Hooks, Classpath Hooks
212 @comment  node-name,  next,  previous,  up
213
214 @section @code{java.lang}
215
216 @code{java.lang} is the core Java package, being imported automatically by all
217 classes.  It includes basic classes as @code{Object} and @code{String}.
218 A VM must implement at least some parts of this package in order to
219 become operable.
220
221 @menu
222 * java.lang.VMClass::
223 * java.lang.VMObject::
224 * java.lang.VMClassLoader::
225 * java.lang.VMSystem::
226 * java.lang.VMThrowable::
227 * java.lang.VMCompiler::
228 * java.lang.VMDouble::
229 * java.lang.VMFloat::
230 * java.lang.VMProcess::
231 * java.lang.VMRuntime::
232 * java.lang.VMString::
233 * java.lang.VMThread::
234 * java.lang.VMMath::
235 @end menu
236
237 @node java.lang.VMClass, java.lang.VMObject ,java.lang,java.lang
238 @subsection @code{java.lang.VMClass}
239
240 The core class, @code{java.lang.Class}, and the corresponding VM class,
241 @code{java.lang.VMClass}, provide two main functions within GNU Classpath.
242
243 @enumerate
244 @item For basic VM operation, @code{java.lang.Class} provides the link between
245 the Java-based representation of a class it embodies and the VM's own
246 internal structure for a class.  @xref{VM Hooks}.
247
248 @item As far as the user is concerned, the main function of
249 @code{java.lang.Class} is as an entry point to the reflection
250 facilities, and so it also provides this functionality, backed by the
251 VM class.
252 @end enumerate
253
254 This VM class lists the following methods, organized by the version of the
255 Java specification in which they occur.  All are @code{native}, unless
256 otherwise specified, and pertain to reflection.  As a result, the VM only
257 needs to implement these methods in order to provide reflection support,
258 and then only to the degree required.
259
260 @itemize @bullet
261 @item 1.0
262 @itemize @bullet
263 @item @code{isInterface(Class)} -- This is simply a property test, and matches
264 the presence of an appropriate flag within the class file.
265 @item @code{getName(Class)} -- Returns the fully-qualified name of the class.
266 @item @code{getSuperclass(Class)} -- Returns a @code{Class} instance which
267 represents the superclass.  Again, the class file contains an element directly
268 relating to this.  @code{null} is returned for primitives, interfaces and
269 @code{Object}.
270 @item @code{getInterfaces(Class)} -- Same as the above, but the implemented
271 or extended interfaces rather than the superclass.  An empty array should
272 be returned, rather than @code{null}.
273 @item @code{getDeclaredClasses(Class,boolean)} -- Returns the internal classes
274 this instance declares directly.  The flag determines whether or not the
275 VM should filter out non-public classes.
276 @item @code{getDeclaredFields(Class,boolean)} -- The same for fields.
277 @item @code{getDeclaredMethods(Class,boolean)} -- And for methods.
278 @item @code{getDeclaredConstructors(Class,boolean)} -- And constructors.
279 @item @code{getClassLoader(Class)} -- Returns the @code{ClassLoader} instance
280 which is responsible for the specified class.
281 @item @code{forName(String, boolean, ClassLoader)} -- The VM should create a
282 @code{Class} instance corresponding to the named class.  As noted in
283 @ref{VM Hooks}, the internal content of the instance is the
284 responsibility of the VM@.  The supplied class loader is recorded as that
285 which loaded the class, and the boolean specifies whether or not to
286 run the class initializer.
287 @item @code{isArray(Class)} -- Another property test, corresponding to a
288 class file flag.
289 @item @code{initialize(Class)} -- The VM should initialize the class fully,
290 if it has not already done so.
291 @item @code{loadArrayClass(String,ClassLoader)} -- This is called if
292 @code{forName} returns @code{null} and the string specifies an array class.
293 The specified array class should be loaded with the supplied class loader.
294 @item @code{throwException(Throwable)} -- The VM should throw the supplied
295 checked exception, without declaring it.
296 @end itemize
297 @item 1.1
298 @itemize @bullet
299 @item @code{isInstance(Class,Object)} -- This is a reflection-based equivalent
300 of the @code{instanceof} operator.
301 @item @code{isAssignableFrom(Class,Class)} -- Mainly a shorthand for the above,
302 removing the need to create an instance to test assignability.  
303 @item @code{isPrimitive(Class)} -- Returns true if this class is simply
304 a representation of one of the primitive types: @code{boolean}, @code{byte},
305 @code{char}, @code{short}, @code{int}, @code{long}, @code{float},
306 @code{double} and @code{void}.
307 @item @code{getComponentType(Class)} -- Produces a @code{Class} instance which
308 represents the type of the members of the array the class instance represents.
309 Classes which don't represent an array type return @code{null}.
310 @item @code{getModifiers(Class,boolean)} -- Returns an integer which encodes
311 the class' modifiers, such as @code{public}.  Again, this relates to
312 information stored in the class file.
313 @item @code{getDeclaringClass(Class)} -- Returns the class that declared
314 an inner or member class, or @code{null} if the instance refers to a top-level
315 class.
316 @end itemize
317 @item 1.5
318 @itemize @bullet
319 @item @code{isSynthetic(Class)} -- Returns true if the flags for this class
320 mark it as synthetic.
321 @item @code{isAnnotation(Class)} -- Returns true if the flags for this class
322 mark it as an annotation.
323 @item @code{isEnum(Class)} -- Returns true if the flags for this class
324 mark it as an enumeration.
325 @item @code{getSimpleName(Class)} -- Returns the simple name of the class.
326 A default implementation is provided, but a more efficient version may instead
327 be provided by the VM.
328 @item @code{getCanonicalName(Class)} -- Returns the canonical name of the
329 class.  A default implementation is provided, but a more efficient
330 version may instead be provided by the VM.
331 @item @code{getEnclosingClass(Class)} -- Returns the immediately enclosing
332 class (null for a top-level class).
333 @item @code{getEnclosingConstructor(Class)} -- Returns the constructor
334 which immediately encloses the supplied class.
335 @item @code{getEnclosingMethod(Class)} -- Returns the method
336 which immediately encloses the supplied class.
337 @item @code{getClassSignature(Class)} -- Returns the generic signature of
338 the class or null if there isn't one.
339 @item @code{isAnonymousClass(Class)} -- Returns true if the class is an
340 anonymous class.
341 @item @code{isLocalClass(Class)} -- Returns true if the class is an
342 local class.
343 @item @code{isMemberClass(Class)} -- Returns true if the class is an
344 member class.
345 @end itemize
346 @end itemize
347
348 @node java.lang.VMObject, java.lang.VMClassLoader, java.lang.VMClass, java.lang
349 @subsection @code{java.lang.VMObject}
350
351 @code{VMObject} is the bridge between the low level @code{Object}
352 facilities such as making a clone, getting the class of the object and
353 the wait/notify semantics.  This is accomplished using the following
354 @code{native} methods.
355
356 @itemize @bullet
357 @item @code{getClass(Object)} -- Returns the @code{Class} instance for the
358 object.  @code{Class} objects are produced by the VM, as described in
359 @ref{VM Hooks}.
360 @item @code{clone(Cloneable)} -- The VM should produce a low-level clone of the
361 specified object, creating a field-by-field shallow copy of the original.
362 The only difference between the two is that the new object should still be
363 @code{finalizable}, even if the original is not.
364 @item @code{notify(Object)} -- The VM should choose one of the threads waiting
365 for a lock on the specified object arbitrarily, and wake it.  If the current
366 thread does not currently hold the lock on the object, then an
367 @code{IllegalMonitorStateException} should be thrown.
368 @item @code{notifyAll(Object)} -- Same as the above, but all threads are
369 awakened.
370 @item @code{wait(Object,long,int)} -- The VM should set the current thread
371 into a waiting state, which persists until it receives a notify signal or the
372 specified time (in milliseconds and nanoseconds) is exceeded.  The nanoseconds
373 restriction may be ignored if such granularity is not available, and a
374 @code{IllegalMonitorStateException} should be thrown if the current thread
375 doesn't own the object.
376 @end itemize
377
378 @node java.lang.VMClassLoader, java.lang.VMSystem, java.lang.VMObject, java.lang
379 @subsection @code{java.lang.VMClassLoader}
380 @code{VMClassLoader} provides methods for defining and resolving core and
381 primitive classes, as well as handling resources, packages and assertions.
382 The class is a mixture of @code{native} methods and Java-based
383 implementations, with some of the latter being @emph{stubs}.
384
385 @itemize @bullet
386 @item Native Methods
387 @itemize @bullet
388 @item @code{defineClass(ClassLoader,String,byte[],int,int,ProtectionDomain)}
389 -- The VM should create a @code{Class} instance from the supplied byte array.
390 @item @code{resolveClass(Class)} -- Resolve references to other classes in the
391 supplied class.
392 @item @code{loadClass(name,boolean)} -- Load a class using the bootstrap
393 loader.
394 @item @code{getPrimitiveClass(char)} -- The VM should provide a @code{Class}
395 implementation for one of the primitive classes.  The supplied character
396 matches the JNI code for the primitive class e.g.@: `B' for byte and
397 `Z' for boolean.
398 @end itemize
399 @item Java Methods
400 @itemize @bullet
401 @item @code{getResource(String)} -- The default implementation calls
402 @code{getResources} and returns the first element in the returned enumeration,
403 or @code{null} if there are no elements.
404 @item @code{getResources(String)} -- By default, this compiles a list of
405 URLs via the boot class path.  Any matching files within a zip file are added,
406 and directories on the boot class path are automatically converted to file
407 URLs that refer to join the directory with the resource name (whether or not
408 it actually exists).
409 @item @code{getPackage(String)} -- Always returns null, which may be suitable
410 if the VM does not wish to return a @code{Package} implementation. Otherwise,
411 it may be necessary to make this a @code{native} method.
412 @item @code{getPackages()} -- As with the last, a default stub implementation
413 exists (returning an empty array) which may be replaced if support is
414 required. 
415 @item @code{defaultAssertionStatus()} -- A stub which can be implemented
416 by VMs providing assertion support.  At present, it always returns @code{true}.
417 @item @code{packageAssertionStatus()} -- Much the same status as the above.
418 The method should return a map converting package names to boolean status
419 values.  The stub implementation provides an empty map.
420 @item @code{classAssertionStatus()} -- Same as the last, but for classes.
421 @item @code{getSystemClassLoader()} -- The default calls @code{ClassLoader}
422 to create a new auxiliary class loader with a system and extension class
423 loader.  The VM may wish to replace it if it wishes to supply its own custom
424 system class loader.
425 @end itemize
426 @end itemize
427 @node java.lang.VMSystem, java.lang.VMThrowable, java.lang.VMClassLoader, java.lang
428 @subsection @code{java.lang.VMSystem}
429 @code{VMSystem} handles the default I/O streams, provides access to the
430 system clock and environment variables and provides methods for
431 @code{System.arraycopy} and the @code{identityHashCode} of an
432 @code{Object}.  It consists of @code{native} methods, but the default
433 implementation also provides some helper methods to simplify stream
434 creation.  
435
436 @itemize @bullet
437 @item Native Methods
438 @itemize @bullet
439 @item @code{arraycopy(Object,int,Object,int,int)} -- The VM should copy
440 a specified number of array objects from one array to another, with 
441 appropriate checks for compatible typing, available elements and space.
442 The VM should be able to perform this more efficiently using native code
443 and direct memory manipulation than would have been achieved by using Java.
444 @item @code{identityHashCode(Object)} -- This is the hashcode for
445 @code{Object}, which relates to the actual location of the object in memory.
446 @item @code{setIn(InputStream)} -- Set the system input stream.
447 @item @code{setOut(PrintStream)} -- Set the system output stream.
448 @item @code{setErr(PrintStream)} -- Set the system error stream.
449 @item @code{currentTimeMillis()} -- Gets the system time in milliseconds.
450 @item @code{getenv(String)} -- Returns the value of the specified environment
451 variable.
452 @item @code{getenv()} -- Returns a list of `name=value' pairs which correspond
453 to the environment variables.
454 @end itemize
455 @item Java Methods
456 @itemize @bullet
457 @item @code{makeStandardInputStream()} -- Helps provide the functionality of
458 @code{System.in} by wrapping the appropriate file descriptor in a
459 buffered file input stream.  VMs may choose to create the stream from
460 the descriptor differently rather than using this method.
461 @item @code{makeStandardOutputStream()} -- Helps provide the functionality of
462 @code{System.out} by wrapping the appropriate file descriptor in a buffered
463 file output stream.  VMs may choose to create the stream from the descriptor
464 differently rather than using this method.
465 @item @code{makeStandardErrorStream()} -- Helps provide the functionality of
466 @code{System.err} by wrapping the appropriate file descriptor in a buffered
467 file output stream.  VMs may choose to create the stream from the descriptor
468 differently rather than using this method.
469 @end itemize
470 @end itemize
471
472 Classpath also provides native implementations of
473
474 @itemize @bullet
475 @item @code{setIn(InputStream)} 
476 @item @code{setOut(PrintStream)} 
477 @item @code{setErr(PrintStream)} 
478 @item @code{currentTimeMillis()} 
479 @item @code{getenv(String)}
480 @end itemize
481
482 making a VM implementation optional.
483
484 @node java.lang.VMThrowable, java.lang.VMCompiler, java.lang.VMSystem, java.lang
485 @subsection @code{java.lang.VMThrowable}
486 @code{VMThrowable} is used to hold the VM state of a throwable, created either
487 when a @code{Throwable} is created or the @code{fillInStackTrace()} method is
488 called (i.e., when the actual stack trace is needed, as a lot of exceptions are
489 never actually used).  The actual class has two @code{native} methods,
490 one (@code{fillInStackTrace()}) being a method of the class used to obtain
491 instances, and the other an instance method, @code{getStackTrace()}.
492 @itemize @bullet
493 @item @code{fillInStackTrace(Throwable)} -- The VM should return the current
494 execution state of the @code{Throwable} in the form of a @code{VMThrowable}
495 instance.  The VM may also return @code{null} if it does not support this
496 functionality.
497 @item @code{getStackTrace()} -- This is used to create a real
498 @code{StackTraceElement} array for the exception, using the state data
499 stored during creation of the instance.
500 @end itemize
501
502 @node java.lang.VMCompiler, java.lang.VMDouble, java.lang.VMThrowable, java.lang
503 @subsection @code{java.lang.VMCompiler}
504
505 @code{VMCompiler} provides an interface for VMs which wish to provide
506 JIT compilation support.  The default implementation is simply a series
507 of stubs. The property, @code{java.compiler}, should point to a library
508 containing the function @code{java_lang_Compiler_start()} if such support
509 is to be provided.
510
511 @itemize @bullet
512 @item @code{compileClass(Class)} -- Invoke the compiler to compile the specific
513 class, returning @code{true} if successful.
514 @item @code{compileClasses(String)} -- The compiler should compile the classes
515 matching the specified string, again returning @code{true} on success.
516 @item @code{command(Object)} -- The object represents a command given to the
517 compiler, and is specific to the compiler implementation.
518 @item @code{enable} -- Enable the operation of the compiler.
519 @item @code{disable} -- Disable compiler operation.
520 @end itemize
521
522 @node java.lang.VMDouble, java.lang.VMFloat, java.lang.VMCompiler, java.lang
523 @subsection @code{java.lang.VMDouble}
524
525 @code{VMDouble} provides native support for the conversion and parsing
526 of doubles.
527
528 @itemize @bullet
529 @item @code{doubleToRawLongBits(double)} -- Converts the double to the IEEE 754
530 bit layout, preserving NaNs.
531 @item @code{longBitsToDouble(long)} -- This is the inverse of the last method,
532 preserving NaNs so that the output of one can be fed into the other without
533 data loss.
534 @item @code{toString(double,boolean)} -- Converts the double to a string,
535 giving a shorter value if the flag @code{isFloat} is @code{true}, indicating
536 that the conversion was requested by @code{java.lang.Float} rather than
537 @code{java.lang.Double}.
538 @item @code{initIDs} -- Used by JNI-based solutions to initialize the cache
539 of the static field IDs.  The default @code{VMDouble} implementation has a
540 static initializer which loads the JNI library and calls this method.
541 @item @code{parseDouble} -- Turn the string into a usable double value.
542 @end itemize
543
544 Classpath provides native implementations of all these, making VM
545 implementation optional.
546
547 @node java.lang.VMFloat, java.lang.VMProcess, java.lang.VMDouble, java.lang
548 @subsection @code{java.lang.VMFloat}
549
550 @code{VMFloat} provides native support for the conversion of floats.
551
552 @itemize @bullet
553 @item @code{floatToRawIntBits(float)} -- Converts the float to the IEEE 754
554 bit layout, preserving NaNs.
555 @item @code{intBitsToFloat(int)} -- This is the inverse of the last method,
556 preserving NaNs so that the output of one can be fed into the other without
557 data loss.
558 @end itemize
559
560 Classpath provides native implementations of all these, making VM
561 implementation optional.
562
563 @node java.lang.VMProcess, java.lang.VMRuntime, java.lang.VMFloat, java.lang
564 @subsection @code{java.lang.VMProcess}
565
566 @code{VMProcess} handles the execution of external processes.  In the
567 default implementation, threads are spawned and reaped by @code{ProcessThread}.
568 A constructor creates a new @code{VMProcess}, which extends rather than
569 complements @code{Process}, using an array of arguments, an array of
570 environment variables and a working directory.  The instance maintains
571 system input, output and error streams linked to the external process.
572 Three @code{native} methods are used, and implementations are provided
573 for all three by Classpath, making VM implementation optional.  These use
574 the POSIX functions, @code{fork()}, @code{waitpid()} and @code{kill()}.
575
576 @itemize @bullet
577 @item @code{nativeSpawn(String[],String[],File,boolean)} -- The VM should
578 create a new process which uses the specified command-line arguments,
579 environment variables and working directory.  Unlike the other two
580 methods, this method is linked to an instance, and must call
581 @code{setProcessInfo()} with the results before returning.  The
582 boolean argument maps to the @code{redirectErrorStream} property of
583 @code{java.lang.ProcessBuilder}.  When true, the output and error streams
584 are merged.
585 @item @code{nativeReap()} -- This is called to perform a reap of any
586 zombie processes, and should not block, instead returning a boolean as to
587 whether reaping actually took place.
588 @item @code{nativeKill(long)} -- The VM should terminate the specified PID.
589 @end itemize
590
591 @node java.lang.VMRuntime, java.lang.VMString, java.lang.VMProcess, java.lang
592 @subsection @code{java.lang.VMRuntime}
593
594 The @code{VMRuntime} class provides a series of native methods
595 which divulge information about the runtime or invoke certain
596 operations.  This includes retrieving the amount of available memory,
597 and scheduling the garbage collector.  There are two exceptions: the
598 @code{enableShutdownHooks} method, which allows the VM to put in its own
599 shutdown hooks when @code{Runtime.addShutdownHook()} is first invoked,
600 and @code{exec(String[],String[],File)} which spawns an external process.
601 These are Java-based static methods instead.  The first is simply a stub by
602 default, while the second simply links to the functionality of
603 @code{VMProcess} (and should be changed if a different @code{Process}
604 implementation is used).
605
606 @itemize @bullet
607 @item @code{availableProcessors()} -- Returns the number of processors 
608 available to the VM.
609 @item @code{freeMemory()} -- Returns the amount of memory the VM has available
610 on the heap for allocating.
611 @item @code{totalMemory()} -- Returns the size of the heap.
612 @item @code{maxMemory()} -- Returns the maximum memory block the VM will
613 attempt to allocate.  May be simply @code{Long.MAX_VALUE} (8 exabytes!)
614 @item @code{gc()} -- Allows users to explicitly invoke the garbage collector.
615 This is a suggestion to the VM, rather than a command, and the garbage
616 collector should run anyway @emph{without} it being invoked.
617 @item @code{runFinalization()} -- Like the above, but related to the
618 finalilzation of objects rather than the garbage collector.
619 @item @code{runFinalizationForExit()} -- Called immediately prior to VM
620 shutdown in order to finalize all objects (including `live' ones)
621 @item @code{traceInstructions(boolean)} -- This turns on and off the optional
622 VM functionality of printing a trace of executed bytecode instructions.
623 @item @code{traceMethodCalls(boolean)} -- This turns on and off the optional
624 VM functionality of printing a trace of methods called.
625 @item @code{runFinalizersOnExit(boolean)} -- A toggleable setting for
626 running the finalization process at exit.
627 @item @code{exit(int)} -- The VM should shutdown with the specified exit code.
628 @item @code{nativeLoad(String,ClassLoader)} -- Attempts to load a file,
629 returning an integer which is non-zero for success.  Nothing happens if the
630 file has already been loaded.
631 @item @code{mapLibraryName(String)} -- The VM should map the system-independent
632 library name supplied to the platform-dependent equivalent (e.g.@: a @code{.so}
633 or @code{.dll} file)
634 @end itemize
635
636 @node java.lang.VMString, java.lang.VMThread, java.lang.VMRuntime, java.lang
637 @subsection @code{java.lang.VMString}
638 @code{VMString} is responsible for handling interned strings.  If two strings
639 are equal (using the @code{equals()} method), then the results of calling
640 the @code{intern()} method on each of them makes them equal
641 (using @code{==}).  Thus, the same string object is always returned by
642 @code{intern} if the two strings are equal.  The default implementation
643 is Java-based and implements @code{intern(String)} by maintaining a
644 @code{WeakHashMap} which links the strings to their @code{WeakReference}.
645 A new mapping is created for each new string being @code{intern}ed.  
646 A VM may implement this differently by implementing this method,
647 which is @code{static} and the only one in @code{VMString}.
648
649 @node java.lang.VMThread, java.lang.VMMath, java.lang.VMString, java.lang
650 @subsection @code{java.lang.VMThread}
651
652 @code{VMThread} provides the link between Java's threads and the platform
653 threading support.  A @code{VMThread} is created via a private constructor
654 and linked to a @code{Thread} instance.  This occurs when the @code{Thread}
655 instance is started by the static @code{create(Thread,long)} method (the second
656 argument requests a certain stack size, usually zero).  The thread itself is
657 executed via the @code{run()} method, which handles any problems with the
658 running of the thread and its eventual death.
659
660 @code{VMThread} provides the following accessors and mutators for accessing
661 the thread state via @code{VMThread},
662
663 @itemize @bullet
664 @item @code{getName()}
665 @item @code{setName(String)}
666 @item @code{getPriority()}
667 @item @code{setPriotity(int)}
668 @item @code{isDaemon()}
669 @end itemize
670
671 all of which refer to the @code{Thread} instance. @code{setPriority(int)} also
672 calls the appropriate native method.  @code{stop(Throwable)} similarly wraps
673 a native method, merely adding in a check for the state of the thread.
674
675 The default implementation also provides Java-based implementations of
676 @code{join(long,int)}, @code{sleep(long,int)} and
677 @code{holdsLock(Object)}.  @code{join} and @code{sleep} simply wait for
678 the appropriate amount of time, with @code{join} additionally waiting
679 for the thread instance to become @code{null}.  @code{holdsLock} simply
680 checks if an object is locked by the current thread by trying to invoke
681 the @code{notify} method, and catching the failing exception if this is
682 not the case.
683
684 The remainder of the class is a series of @code{native} methods, some of
685 which are mandatory for VM implementation and others which provide optional
686 or deprecated functionality.
687
688 @itemize @bullet
689 @item Mandatory Instance Methods
690 @itemize @bullet
691 @item @code{start(long)} -- The VM should create the native thread and start
692 it running using the @code{run} method of the @code{VMThread} instance on
693 which this method is called.
694 @item @code{interrupt()} -- The VM should interrupt the running thread and
695 throw an appropriate exception.
696 @item @code{isInterrupted()} -- Checks the interrupted state of the thread.
697 @item @code{suspend()} -- The thread should be suspended until resumed.
698 @item @code{resume()} -- The thread should be resumed from its suspended state.
699 This pair of methods are deprecated, due to the possibility of a deadlock
700 occurring when a thread with locks is suspended.
701 @item @code{nativeSetPriority(int)} -- Called by @code{setPriority}
702 to allow the setting to flow down to the native thread.
703 @item @code{nativeStop(Throwable)} -- The VM should stop the thread abnormally
704 and throw the specified exception.  This is clearly deprecated, due to the
705 ambiguous state an abruptly-stopped thread may leave.
706 @item @code{getState()} -- Returns the VM's impression of the current state
707 of the thread.  The applicable states are supplied by the @code{State}
708 enumeration in @code{java.lang.Thread}.
709 @end itemize
710 @item Mandatory Class Methods
711 @itemize @bullet
712 @item @code{currentThread()} -- Return a reference to the thread currently
713 being executed.
714 @item @code{yield()} -- The VM should allow some other thread to run.
715 The current thread maintains its locks even though it stops executing for
716 the time being.
717 @item @code{interrupted()} -- A shortcut to obtaining the interrupted state
718 of the current thread.
719 @end itemize
720 @item Other Methods
721 @itemize @bullet
722 @item @code{countStackFrames()} -- Returns a count of the number of stack
723 frames in the thread.  This depends on the deprecated method @code{suspend()}
724 having returned true, and is thus deprecated as a result.
725 @end itemize
726 @end itemize
727
728 @node java.lang.VMMath,, java.lang.VMThread, java.lang
729 @subsection @code{java.lang.VMMath}
730
731 The @code{VMMath} class provides a series of native methods
732 for some of the mathematical functions present in @code{java.lang.Math}.
733 Classpath provides a default implementation of these which maps the
734 functions to those provided by @code{fdlibm}.  VM implementors are welcome
735 to replace this with more efficient implementations, as long as the accuracy
736 contract of these methods, specified in @code{java.lang.Math}, is maintained.
737
738 @itemize @bullet
739 @item 1.0
740 @itemize @bullet
741 @item @code{sin(double)} -- Returns the sine value for the given angle.
742 @item @code{cos(double)} -- Returns the cosine value for the given angle.
743 @item @code{tan(double)} -- Returns the tangent value for the given angle.
744 @item @code{asin(double)} -- Returns the arc sine value for the given angle.
745 @item @code{acos(double)} -- Returns the arc cosine value for the given angle.
746 @item @code{atan(double)} -- Returns the arc tangent value for the given angle.
747 @item @code{atan2(double,double)} -- Returns the arc tangent of the ratio of
748 the two arguments.
749 @item @code{exp(double)} -- Returns the exponent raised to the given power.
750 @item @code{log(double)} -- Returns the natural logarithm for the given value.
751 @item @code{sqrt(double)} -- Returns the square root of the value.
752 @item @code{pow(double,double)} -- Returns x to the power of y.
753 @item @code{IEEEremainder(double,double)} -- Returns the IEEE 754 remainder
754 for the two values.
755 @item @code{ceil(double)} -- Returns the nearest integer >= the value.
756 @item @code{floor(double)} -- Returns the nearest integer <= the value.
757 @item @code{rint(double)} -- Returns the nearest integer or the even one
758 if the distance between the two is equal.
759 @end itemize
760 @item 1.5
761 @itemize @bullet
762 @item @code{cbrt(double)} -- Returns the cube root of the value.
763 @item @code{cosh(double)} -- Returns the hyperbolic cosine value for the given
764 angle.
765 @item @code{expm1(double)} -- Returns the exponent of the value minus one.
766 @item @code{hypot(double,double)} -- Returns the hypotenuse corresponding to
767 x and y.
768 @item @code{log10(double)} -- Returns the base 10 logarithm of the given value.
769 @item @code{log1p(double)} -- Returns the natural logarithm of the value plus
770 one.
771 @item @code{sinh(double)} -- Returns the hyperbolic sine value for the given
772 angle.
773 @item @code{tanh(double)} -- Returns the hyperbolic tangent value for the given angle.
774 @end itemize
775 @end itemize
776
777 @node gnu.classpath, java.util, java.lang, Classpath Hooks
778 @section @code{gnu.classpath}
779
780 The @code{gnu.classpath} package provides Classpath-specific functionality,
781 primarily relating to the features in @code{java.lang}.  At present, this
782 includes the context of a class (the stack) and the system properties.
783
784 @menu
785 * gnu.classpath.VMStackWalker::
786 * gnu.classpath.VMSystemProperties::
787 * gnu.classpath.Unsafe::
788 @end menu
789
790 @node gnu.classpath.VMStackWalker,gnu.classpath.VMSystemProperties,gnu.classpath,gnu.classpath
791 @subsection @code{gnu.classpath.VMStackWalker}
792
793 @code{VMStackWalker} provides access to the class context or stack.  The
794 default implementation consists of a @code{native} @code{static} method,
795 @code{getClassContext()}, which obtains the class context, and two helper
796 methods which obtain the calling class (the 3rd element in the context array)
797 and its class loader, respectively.
798
799 @itemize @bullet
800 @item @code{getClassContext()} -- The VM should return an array of
801 @code{Class} objects, each of which relates to the method currently being
802 executed at that point on the stack.  Thus, the first item (index 0) is the
803 class that contains this method.
804 @item @code{getCallingClass()} -- A Java-based helper method which returns
805 the @code{Class} object which contains the method that called the method
806 accessing @code{getCallingClass()}. 
807 @item @code{getCallingClassLoader()} -- Like the last, but returning the class
808 loader of the class.
809 @end itemize
810
811 @node gnu.classpath.VMSystemProperties,gnu.classpath.Unsafe,gnu.classpath.VMStackWalker,gnu.classpath
812 @subsection @code{gnu.classpath.VMSystemProperties}
813
814 @code{VMSystemProperties} allows the VM to hook into the property creation
815 process, both before and after the system properties are added by GNU
816 Classpath.  The default implementation assumes that the VM will add its
817 properties first, by making the pre-initialisation method @code{native},
818 and that the Classpath properties may then be altered by a Java-based
819 post-initialisation method.
820
821 As these methods are called as part of the bootstrap process, caution should
822 be used as to what classes are used, and properties should only be set
823 using @code{Properties.setProperty()}.  Specifically, I/O classes should be
824 avoided at this early stage.
825
826 @itemize @bullet
827 @item @code{preInit(Properties)} -- Allows the VM to add properties
828 @emph{before} the Classpath properties are added. The default implementation
829 includes a full list of properties that @emph{must} be added by the VM, but
830 additional VM-specific ones may also be added.  
831 @item @code{postInit(Properties)} -- Same as the last, but called after the
832 Classpath properties have been added.  The main purpose of this is to allow
833 the VM to alter the properties added by GNU Classpath to suit it.
834 @end itemize
835
836 @node gnu.classpath.Unsafe,,gnu.classpath.VMSystemProperties,gnu.classpath
837 @subsection @code{gnu.classpath.Unsafe}
838
839 The @code{Unsafe} class provides access to some low-level unsafe operations
840 as required by the addition of the java.util.concurrent classes.  These
841 focus on direct memory access to the fields within the VM and providing
842 atomic update methods.
843
844 @itemize @bullet
845 @item @code{objectFieldOffset(Field)} -- Provides the caller with the memory
846 offset of a particular field.
847 @item @code{compareAndSwap*(Object,long,*,*)} -- One of these methods is
848 provided for each of int, long and Object (hence the *s).  The value of
849 a field pointed to by the given Object and offset is compared with the
850 first value and replaced with the second if they are the same.  The reason
851 for this method is to make this change operation atomic.
852 @item @code{put/get*(Object,long,*)} -- These are like the last set of
853 methods, handling integers, longs and Objects, but the field is always
854 changed on a put.  Different methods are provided for different semantics.
855 Ordered variants perform a lazy put, in that the change does not
856 immediately propogate to other threads, while the others provide
857 volatile or 'normal' semantics.
858 @item @code{arrayBaseOffset(Class)} and @code{arrayIndexScale(Class)} --
859 These two methods allow an array class to be traversed by pointer
860 arithmetic, by gaining the address of the first element and then
861 scaling appropriately for the later ones.
862 @item @code{park(boolean,long)} and @code{unpark(Thread)} -- These methods
863 block and unblock threads respectively, with an optional timeout being
864 provided for the blocking.  @code{unpark} is unsafe as the thread may have
865 been destroyed by native code. 
866 @end itemize
867
868 @node java.util, java.io, gnu.classpath, Classpath Hooks
869 @section java.util
870
871 The @code{java.util} VM hooks provide links between the mix of functionality
872 present in that package, which includes collections, date and time handling
873 and parsing.  At present, there is only one hook, which connects GNU Classpath
874 to the timezone information provided by the underlying platform.
875
876 @menu
877 * java.util.VMTimeZone::
878 @end menu
879
880 @node java.util.VMTimeZone,,java.util,java.util
881 @subsection @code{java.util.VMTimeZone}
882
883 @code{VMTimeZone} joins @code{TimeZone} to the platform timezone information
884 via the static method, @code{getDefaultTimeZoneId()}.  The VM hook is
885 expected to return a @code{TimeZone} instance that represents the current
886 timezone in use by the platform.  The default implementation provides
887 this functionality for POSIX or GNU-like systems, and VMs that want this
888 functionality can keep this implementation and implement the native
889 method, @code{getSystemTimeZoneId()}.  This method is only called when
890 obtaining the timezone name from the @code{TZ} environment variable,
891 @code{/etc/timezone} and @code{/etc/localtime} all fail.  This fallback
892 mechanism also means that a system which doesn't provide the above three
893 methods, but does provide a timezone in string form, can still use this
894 implementation.
895
896 @node java.io, java.security, java.util, Classpath Hooks
897 @section java.io
898
899 The @code{java.io} package is heavily reliant on access to the I/O facilities
900 of the underlying platform.  As far as its VM hooks go, they provide two
901 areas of functionality to GNU Classpath, these being
902
903 @itemize @bullet
904 @item File and directory queries and manipulation
905 @item Serialization of objects
906 @end itemize
907
908 The first corresponds directly to most of the @code{File} class, while
909 the latter underlies the functionality provided by the
910 @code{ObjectInputStream} and @code{ObjectOutputStream}.  More low-level I/O
911 is provided by @ref{java.nio}.
912
913 @menu
914 * java.io.VMFile::
915 * java.io.VMObjectInputStream::
916 * java.io.VMObjectStreamClass::
917 @end menu
918
919 @node java.io.VMFile,java.io.VMObjectInputStream,java.io,java.io
920 @subsection @code{java.io.VMFile}
921
922 @code{VMFile} allows GNU Classpath's @code{File} representations to
923 probe and modify the file system using the native functions of the
924 platform.  The default implementation (which consists of both a
925 @code{VMFile} class and the native methods) is primarily UNIX-centric,
926 working with POSIX functions and assuming case-sensitive filenames,
927 without the restriction of the 8.3 format.  It consists mainly of
928 @code{static} @code{native} methods, with a few Java helper methods.
929 The native methods represent the file as a string containing its path,
930 rather than using the object itself.
931
932 @itemize @bullet
933 @item Native Methods
934 @itemize @bullet
935 @item @code{lastModified(String)} -- The native method should return a
936 @code{long} value that represents the last modified date of the file.
937 @item @code{setReadOnly(String)} -- Sets the file's permissions to read only,
938 in whichever way this is realised by the platform.
939 @item @code{create(String)} -- Create the named file.
940 @item @code{list(String)} -- The native method opens the named directory,
941 reads the contents and returns them as a Java @code{String} array.
942 @item @code{renameTo(String,String)} -- Renames the first file to the second.
943 @item @code{length(String)} -- Returns a @code{long} value representing
944 the file size.
945 @item @code{exists(String)} -- Tests for the existence of the named file
946 or directory.
947 @item @code{delete(String)} -- Deletes the file or directory.
948 @item @code{setLastModified(String,long)} -- Change the last modified time.
949 @item @code{mkdir(String)} -- Creates the named directory.
950 @item @code{isFile(String)} -- Tests that the named path references a file.
951 @item @code{canWrite(String)} -- Tests that the file can be written to.
952 This method is @code{synchronized}, so the object is locked during the check.
953 @item @code{canRead(String)} -- Complement of the last method.
954 @item @code{isDirectory(String)} -- Tests that the named path references
955 a directory.
956 @end itemize
957 @item Java Helper Methods
958 @itemize @bullet
959 @item @code{canWriteDirectory(File)} -- Checks that the directory can be
960 written to, by trying to create a temporary file in it.
961 @item @code{listRoots()} -- Returns the root of a GNU filesystem, i.e.@: `/'
962 in an array.
963 @item @code{isHidden(String)} -- Checks whether the file starts with `.',
964 which is how files are hidden on UNIX-style systems.
965 @item @code{getName(String)} -- Pulls the actual filename from the end of
966 the path, by breaking off the characters after the last occurrence of the
967 platform's file separator.
968 @item @code{getCanonicalForm(String)} -- This converts a UNIX path to
969 its canonical form by removing the `.' and `..' sections that occur within.
970 @end itemize
971 @end itemize
972
973 @node java.io.VMObjectInputStream,java.io.VMObjectStreamClass,java.io.VMFile,java.io
974 @subsection @code{java.io.VMObjectInputStream}
975
976 This class consists of two methods which provide functionality used in
977 deserializing an object.  @code{currentClassLoader()} provides the first
978 user-defined class loader from the class context
979 (@xref{gnu.classpath.VMStackWalker},) via a @code{PrivilegedAction}.
980 @code{allocateObject(Class,Class,Constructor)} is a @code{native} method
981 (a reference implementation is provided) which creates an object but
982 calls the constructor of another class, which is a superclass of the
983 object's class.
984
985 @node java.io.VMObjectStreamClass,,java.io.VMObjectInputStream,java.io
986 @subsection @code{java.io.VMObjectStreamClass}
987
988 @code{VMObjectStreamClass} is a series of @code{static} @code{native}
989 methods that provide some of the groundwork for @code{ObjectStreamClass}
990 and @code{ObjectStreamField}.  @code{hasClassInitializer(Class)} works
991 with the former, and checks for the presence of a static initializer.
992 The remaining methods are of the form @code{setXXXNative(Field,Object,XXX)}
993 and support @code{ObjectStreamField}.  One exists for each of the main types
994 (boolean, float, double, long, int, short, char, byte and object) and is used
995 to set the specified field in the supplied instance to the given value.
996
997 A default implementation is provided for all of them, so a VM implementation
998 is optional.
999
1000 @node java.security, java.net, java.io, Classpath Hooks
1001 @section java.security
1002
1003 The @code{java.security} package provides support for Java's security
1004 architecture.  
1005
1006 @menu
1007 * java.security.VMAccessController::
1008 * java.security.VMSecureRandom::
1009 @end menu
1010
1011 @node java.security.VMAccessController,java.security.VMSecureRandom,java.security,java.security
1012 @subsection @code{java.security.VMAccessController}
1013
1014 The @code{AccessController} is used to perform privileged actions.  Its
1015 hook class, @code{VMAccessController}, maintains the
1016 @code{AccessControlContext} and the default implementation is purely
1017 Java-based.  The VM may choose to replace this with their own.
1018 The methods in the reference version are as follows:
1019
1020 @itemize @bullet
1021 @item @code{pushContext(AccessControlContext)} -- Adds a new context to the
1022 stack for the current thread.  This is called before a privileged action
1023 takes place.
1024 @item @code{popContext()} -- Removes the top context from the stack.  This
1025 is performed after the privileged action takes place.
1026 @item @code{getContext()} -- Either derives a context based on the 
1027 @code{ProtectionDomain}s of the call stack (see the next method) or returns
1028 the top of the context stack.
1029 @item @code{getStack()} -- Provides access to the call stack as a pair of
1030 arrays of classes and method names.  The actual implementation returns
1031 an empty array, indicating that there are no permissions.
1032 @end itemize
1033
1034 @node java.security.VMSecureRandom,,java.security.VMAccessController,java.security
1035 @subsection @code{java.security.VMSecureRandom}
1036
1037 The @code{VMSecureRandom} class is used to provide access to
1038 cryptographically secure random numbers.  The default implementation
1039 of the class runs eight threads that increment counters in a tight
1040 loop, and XORs each counter to produce one byte of seed data. This is
1041 not very efficient, and is not guaranteed to be random (the thread
1042 scheduler is probably deterministic, after all). VM implementors
1043 should provide a version of this class, which implements the method
1044 @code{generateSeed(byte[],int,int)}, so that it fills the buffer using
1045 a random seed from a system facility, such as a system entropy
1046 gathering device or hardware random number generator.  The parameters
1047 are the usual set of buffer, offset and length and the method returns
1048 the number of bytes actually generated, which may be less than that
1049 requested.
1050
1051 @node java.net, java.nio, java.security, Classpath Hooks
1052 @section java.net
1053
1054 The @code{java.net} package is heavily reliant on access to the networking
1055 facilities of the underlying platform.  The VM hooks provide information
1056 about the available network interfaces, and access to lookup facilities
1057 for network addresses.
1058
1059 @menu
1060 * java.net.VMInetAddress::
1061 * java.net.VMNetworkInterface::
1062 @end menu
1063
1064 @node java.net.VMInetAddress,java.net.VMNetworkInterface,java.net,java.net
1065 @subsection @code{java.net.VMInetAddress}
1066
1067 @code{VMInetAddress} is a series of @code{static} @code{native} methods
1068 which provide access to the platform's lookup facilities.  All the methods
1069 are implemented by GNU Classpath, making VM implementation optional, and
1070 are as follows:
1071
1072 @itemize @bullet
1073 @item @code{getLocalHostname()} -- Wraps the @code{gethostname} function, and
1074 falls back on `localhost'.
1075 @item @code{lookupInaddrAny()} -- Returns the value of @code{INADDR_ANY}.
1076 @item @code{getHostByAddr(byte[])} -- Looks up the hostname based on an IP
1077 address.
1078 @item @code{getHostByName(String)} -- The reverse of the last method, it
1079 returns the IP addresses which the given host name resolves to.
1080 @end itemize
1081
1082 @node java.net.VMNetworkInterface,,java.net.VMInetAddress,java.net
1083 @subsection @code{java.net.VMNetworkInterface}
1084
1085 @code{VMNetworkInterface} currently consists of a single @code{static}
1086 @code{native} method, @code{getInterfaces()}, which retrieves the
1087 network interfaces available on the underlying platform as a @code{Vector}.
1088 The current GNU Classpath implementation is a native stub.
1089
1090 @node java.nio, java.nio.channels, java.net, Classpath Hooks
1091 @section java.nio
1092
1093 The @code{java.nio} package is part of the New I/O framework added in
1094 Java 1.4.  This splits I/O into the concepts of @emph{buffers},
1095 @emph{charsets}, @emph{channels} and @emph{selectors}, and
1096 @code{java.nio} defines the buffer classes.  As far as native and VM
1097 code is concerned, the new package needs support for low-level efficient
1098 buffer operations.
1099
1100 @menu
1101 * java.nio.VMDirectByteBuffer::
1102 @end menu
1103
1104 @node java.nio.VMDirectByteBuffer,,java.nio,java.nio
1105 @subsection @code{java.nio.VMDirectByteBuffer}
1106
1107 A @code{ByteBuffer} maintains a buffer of bytes, and allows it to be
1108 manipulated using primitive operations such as @code{get}, @code{put},
1109 @code{allocate} and @code{free}.  A direct buffer avoids intermediate
1110 copying, and uses native data which shouldn't be manipulated by a
1111 garbage collector.  The VM class consists of @code{static} @code{native}
1112 methods, all of which are given default implementations by GNU
1113 Classpath.
1114
1115 @itemize @bullet
1116 @item @code{init()} -- Creates an instance of an appropriate
1117 @code{gnu.classpath.RawData} class.  This class is not garbage
1118 collected, is created natively and is used in the other methods to reference
1119 the buffered data.
1120 @item @code{allocate(int)} -- Allocates the memory for the buffer using
1121 @code{malloc} and returns a reference to the @code{RawData} class.
1122 @item @code{free(RawData)} -- Frees the memory used by the buffer.
1123 @item @code{get(RawData,int)}  -- Returns the data at the specified index.
1124 @item @code{get(RawData,int,byte[],int,int)} -- Copies a section of the
1125 data into a byte array using @code{memcpy}.
1126 @item @code{put(RawData,int,byte)} -- Puts the given data in the buffer
1127 at the specified index.
1128 @item @code{adjustAddress(RawData,int)} -- Adjusts the pointer into the buffer.
1129 @item @code{shiftDown(RawData,int,int,int)} -- Moves the content of the buffer
1130 at an offset down to a new offset using @code{memmove}.
1131 @end itemize
1132  
1133 @node java.nio.channels, gnu.java.nio, java.nio, Classpath Hooks
1134 @section java.nio.channels
1135
1136 Channels provide the data for the buffers with the New I/O packages.
1137 For example, a channel may wrap a file or a socket.  The VM hooks,
1138 at the moment, simply allow the channels to be accessed by @code{java.io}
1139 streams.
1140
1141 @menu
1142 * java.nio.channels.VMChannels::
1143 @end menu
1144
1145 @node java.nio.channels.VMChannels,,java.nio.channels,java.nio.channels
1146 @subsection @code{java.nio.channels.VMChannels}
1147
1148 @code{VMChannels} provides the methods that create the channels or
1149 streams.  The default implementation is in pure Java and simply wraps
1150 the channels in standard I/O classes from @code{java.io}.
1151
1152 @itemize @bullet
1153 @item @code{createStream(Class,Channel)} -- Creates a @code{FileChannel}
1154 which wraps an instance of the specified stream class, created by reflection.
1155 This method is private, and is used by the other two.
1156 @item @code{newInputStream(ReadableByteChannel)} -- Wraps the channel
1157 in a @code{FileInputStream}.
1158 @item @code{newOutputStream(WritableByteChannel)} -- Wraps the channel
1159 in a @code{FileOutputStream}.
1160 @end itemize
1161
1162 @node gnu.java.nio, java.lang.reflect, java.nio.channels, Classpath Hooks
1163 @section gnu.java.nio
1164
1165 The @code{gnu.java.nio} class provides Classpath implementations of the
1166 interfaces provided by @code{java.nio}.  The VM classes provide the native
1167 support necessary to implement @emph{pipes} and @emph{selectors}.
1168
1169 @menu
1170 * gnu.java.nio.VMPipe::
1171 * gnu.java.nio.VMSelector::
1172 @end menu
1173
1174 @node gnu.java.nio.VMPipe,gnu.java.nio.VMSelector,gnu.java.nio,gnu.java.nio
1175 @subsection @code{gnu.java.nio.VMPipe}
1176
1177 @code{VMPipe} provides the native functionality for a uni-directional pipe
1178 between a source and a destination (sink) channel.  It consists of one 
1179 @code{static} @code{native} method, @code{init(PipeImpl,SelectorProvider)},
1180 the reference implementation of which is currently a native stub.  Ideally,
1181 this should initialise the pipe at the native level.
1182
1183 @node gnu.java.nio.VMSelector,,gnu.java.nio.VMPipe,gnu.java.nio
1184 @subsection @code{gnu.java.nio.VMSelector}
1185
1186 A @code{Selector} selects between multiple @code{SelectableChannel}s based
1187 on their readiness and a key set.  The VM hook for the Classpath implementation
1188 of this is @code{VMSelector}, and this allows the actual @code{select()}
1189 operation to be performed.  This is represented by the @code{static}
1190 @code{native} method, @code{select(int[],int[],int[],long)}, and a default
1191 implementation of this is provided.
1192
1193 @node java.lang.reflect, gnu.java.lang, gnu.java.nio, Classpath Hooks
1194 @section @code{java.lang.reflect}
1195 @code{java.lang.reflect} provides the interface to Java's reflection
1196 facilities.  Via reflection, programmers can obtain type information about
1197 a particular instance at runtime or dynamically create new instances.
1198
1199 @menu
1200 * java.lang.reflect.VMArray::
1201 @end menu
1202
1203 @node java.lang.reflect.VMArray,,,java.lang.reflect
1204 @subsection @code{java.lang.reflect.VMArray}
1205
1206 The @code{VMArray} class provides a hook, @code{createObjectArray},
1207 which the VM uses to generate a new non-primitive array of a
1208 particular class and size.  The default implementation simply passes
1209 the job down to the standard JNI function, @code{NewObjectArray}.
1210
1211 @node gnu.java.lang, gnu.java.lang.management, java.lang.reflect, Classpath Hooks
1212 @section @code{gnu.java.lang}
1213
1214 @code{gnu.java.lang} provides VM interfaces for the GNU
1215 implementations of features in java.lang.  Currently, this includes the
1216 implementation of instrumentation.
1217
1218 @menu
1219 * gnu.java.lang.VMInstrumentationImpl::
1220 @end menu
1221
1222 @node gnu.java.lang.VMInstrumentationImpl,,,gnu.java.lang
1223 @subsection @code{gnu.java.lang.VMInstrumentationImpl}
1224
1225 The @code{gnu.java.lang.VMInstrumentationImpl} and
1226 @code{gnu.java.lang.InstrumentationImpl} classes provide an implementation of the
1227 @code{java.lang.instrument.Instrument} interface. 
1228 A @code{InstrumentationImpl} object should be created by the VM when agents
1229 are given in the command line (see the @code{java.lang.instrument} package
1230 documentation). The VM has to set the static field
1231 @code{VMClassLoader.instrumenter} to this object. The VM should implement the
1232 static native methods of the @code{VMInstrumentationImpl} class.
1233
1234 @itemize @bullet
1235 @item @code{isRedefineClassesSupported()} -- Returns true if the JVM supports
1236 class redefinition.
1237 @item @code{redefineClasses()} -- Gives a set of classes with new bytecodes.
1238 The VM must redefine the classes by reading the new bytecodes.
1239 @item @code{getAllLoadedClass()} -- Returns an array of all loaded classes.
1240 @item @code{getInitiatedClass()} -- Returns an array of all classes loaded
1241 by a specific class loader.
1242 @item @code{getObjectSize()} -- Gives the size of an object.
1243 @end itemize
1244
1245 Instrumentation allows to modify the bytecode of a class before it gets read
1246 by the VM@. In GNU Classpath, the @code{ClassLoader.defineClass} method calls
1247 the @code{VMClassLoader.defineClassWithTransformers} method which first checks
1248 if @code{VMClassLoader.instrumenter} is @code{null}. If it's the case, it
1249 directly calls @code{VMClassLoader.defineClass}. If it's not the case, the
1250 method calls at first the @code{InstrumentationImpl.callTransformers} method,
1251 which calls each transformer registered to the @code{InstrumentationImpl}
1252 object and returns a new bytecode array. Then, it calls the
1253 @code{VMClassLoader.defineClass} method with this new bytecode array.
1254
1255 The second use of instrumentation is to redefine a class after it has been
1256 loaded by the VM@. This is done in the Java application by calling the
1257 @code{Instrumentation.redefineClasses} method of the standard interface on
1258 a @code{Instrumentation} object. The @code{InstrumentationImpl.redefineClasses}
1259 method calls the @code{VMInstrumentationImpl.redefineClasses} native method
1260 which must be implemented by the VM@. The implementation should call the
1261 @code{InstrumentationImpl.callTransformers} method.
1262
1263 @node gnu.java.lang.management, java.lang.management, gnu.java.lang, Classpath Hooks
1264 @section @code{gnu.java.lang.management}
1265
1266 @code{gnu.java.lang.management} provides the VM interfaces for the GNU
1267 implementations of the management beans.  
1268
1269 @menu
1270 * gnu.java.lang.management.VMRuntimeMXBeanImpl::
1271 * gnu.java.lang.management.VMClassLoadingMXBeanImpl::
1272 * gnu.java.lang.management.VMThreadMXBeanImpl::
1273 * gnu.java.lang.management.VMMemoryMXBeanImpl::
1274 * gnu.java.lang.management.VMCompilationMXBeanImpl::
1275 * gnu.java.lang.management.VMMemoryPoolMXBeanImpl::
1276 * gnu.java.lang.management.VMMemoryManagerMXBeanImpl::
1277 * gnu.java.lang.management.VMGarbageCollectorMXBeanImpl::
1278 @end menu
1279
1280 @node gnu.java.lang.management.VMRuntimeMXBeanImpl,gnu.java.lang.management.VMClassLoadingMXBeanImpl,,gnu.java.lang.management
1281 @subsection @code{gnu.java.lang.management.VMRuntimeMXBeanImpl}
1282
1283 The @code{gnu.java.lang.management.RuntimeMXBeanImpl} provides an
1284 implementation of the @code{java.lang.management.RuntimeMXBean} interface,
1285 and is supported by VM functionality in the form of
1286 @code{gnu.java.lang.management.VMRuntimeMXBeanImpl}.  This provides a
1287 series of methods, which should be implemented by the virtual machine
1288 in order to provide the required information for the bean.  The VM
1289 methods are generally representative of information that is only
1290 available from the virtual machine, such as the command-line arguments
1291 it was given at startup.
1292
1293 The methods are as follows:
1294
1295 @itemize @bullet
1296 @item @code{(getInputArguments())} -- The VM should supply
1297 a @code{String} array containing each of the command-line
1298 arguments, excluding those that are directed at the
1299 @code{main()} method.  The reference implementation expects
1300 this to be a native method.
1301 @item @code{(getName())} -- The VM developer should choose
1302 an appropriate name for the virtual machine.  This name can
1303 be instance-specific e.g.@: it can include things like the
1304 process identifier or host name of the machine, which only
1305 apply to the current running instance.  Thus, the intention is
1306 that this name refers to the entity that the other information
1307 refers to, rather than the VM in general.  The reference
1308 implementation supplies a default concatenation of the VM
1309 name and version.
1310 @item @code{(getStartTime())} -- This should return the number
1311 of milliseconds at which the virtual machine was started.
1312 The uptime property of the bean is provided relative to this
1313 value.  Again, the reference implementation also expects
1314 this method to be native.
1315 @end itemize
1316
1317 The virtual machine also needs to provide either the
1318 @code{sun.boot.class.path} or @code{java.boot.class.path}
1319 property in order to support the optional boot class path
1320 retrieval functionality.
1321
1322 @node gnu.java.lang.management.VMClassLoadingMXBeanImpl,gnu.java.lang.management.VMThreadMXBeanImpl,gnu.java.lang.management.VMRuntimeMXBeanImpl,gnu.java.lang.management
1323 @subsection @code{gnu.java.lang.management.VMClassLoadingMXBeanImpl}
1324
1325 The @code{gnu.java.lang.management.ClassLoadingMXBeanImpl} provides an
1326 implementation of the @code{java.lang.management.ClassLoadingMXBean} interface,
1327 and is supported by VM functionality in the form of
1328 @code{gnu.java.lang.management.VMClassLoadingMXBeanImpl}.  This provides a
1329 series of methods, which should be implemented by the virtual machine
1330 in order to provide the required information for the bean.  Implementing
1331 this bean requires the VM to monitor when classes are loaded and unloaded,
1332 and provide the option of verbose class loading output.
1333
1334 The methods are as follows:
1335
1336 @itemize @bullet
1337 @item @code{(getLoadedClassCount())} -- This should return
1338 the number of classes that are currently loaded by the VM.
1339 @item @code{(getUnloadedClassCount())} -- This should return
1340 the number of classes that have been loaded by the VM, but
1341 have since been unloaded.
1342 @item @code{(isVerbose())} -- This should return @code{true}
1343 or @code{false}, depending on whether verbose class loading
1344 output is turned or not, respectively.
1345 @item @code{(setVerbose(boolean))} -- This should allow the
1346 verbose class loading output to be turned on and off.
1347 @end itemize
1348
1349 @node gnu.java.lang.management.VMThreadMXBeanImpl,gnu.java.lang.management.VMMemoryMXBeanImpl,gnu.java.lang.management.VMClassLoadingMXBeanImpl,gnu.java.lang.management
1350 @subsection @code{gnu.java.lang.management.VMThreadMXBeanImpl}
1351
1352 The @code{gnu.java.lang.management.ThreadMXBeanImpl} provides an
1353 implementation of the @code{java.lang.management.ThreadMXBean} interface,
1354 and is supported by VM functionality in the form of
1355 @code{gnu.java.lang.management.VMThreadMXBeanImpl}.  This provides a
1356 series of methods, which should be implemented by the virtual machine
1357 in order to provide the required information for the bean.  Implementing
1358 this bean requires the VM to monitor thread-related statistics such as
1359 how often the blocked and waiting states have been entered, as well as
1360 additional optional support for time and contention monitoring.
1361
1362 Optional support is determined by the following properties:
1363
1364 @itemize @bullet
1365 @item @code{gnu.java.lang.management.CurrentThreadTimeSupport} --
1366 This property should be present if the VM supports monitoring the
1367 time used by the current thread.  If time monitoring for all threads
1368 is supported, this need not be provided.
1369 @item @code{gnu.java.lang.management.ThreadTimeSupport} --
1370 This property should be present if the VM supports monitoring the
1371 time used by all threads.
1372 @item @code{gnu.java.lang.management.ThreadContentionSupport} --
1373 This property should be present if the VM supports thread contention
1374 monitoring.
1375 @item @code{gnu.java.lang.management.MonitorUsageMonitoringSupport} --
1376 This property should be present if the VM supports the monitoring
1377 of object monitor usage.
1378 @item @code{gnu.java.lang.management.OwnableSynchronizerUsageMonitoringSupport} --
1379 This property should be present if the VM supports the monitoring
1380 of ownable synchronizer usage.
1381 @end itemize
1382
1383 In addition, the property
1384 @code{gnu.java.lang.management.ThreadTimeInitallyEnabled} may be
1385 set to the @code{String} value, @code{"true"}, if time monitoring
1386 is enabled at startup.
1387
1388 The methods are as follows:
1389
1390 @itemize @bullet
1391 @item @code{(findDeadlockedThreads())} -- This should return
1392 an array of thread identifiers which match threads involved in
1393 deadlock cycles (where each thread is waiting to obtain a lock
1394 held by one of the others) on object monitors or ownable
1395 synchronizers.  This is specified as a native method in the
1396 reference implementation, and is optional.  It is only called
1397 when the VM supports ownable synchronizer monitoring.
1398 @item @code{(findMonitorDeadlockedThreads())} -- This should return
1399 an array of thread identifiers which match threads involved in
1400 deadlock cycles (where each thread is waiting to obtain a lock
1401 held by one of the others) on object monitors.  This is specified
1402 as a native method in the reference implementation.
1403 @item @code{(getAllThreads())} -- This should return an array of
1404 all live threads and set the @code{filled} variable to the number
1405 found.  A default implementation is provided.
1406 @item @code{(getAllThreadIds())} -- This should return an array of
1407 all live thread identifiers.  An implementation is provided against
1408 @code{getAllThreads()} by default.
1409 @item @code{(getCurrentThreadCpuTime())} -- This should return the
1410 approximate number of nanoseconds of CPU time the current thread
1411 has used.  This is an optional native method, which is used by VMs
1412 supporting time monitoring.
1413 @item @code{(getCurrentThreadUserTime())} -- This should return the
1414 approximate number of nanoseconds of user time the current thread
1415 has used.  This is an optional native method, which is used by VMs
1416 supporting time monitoring.
1417 @item @code{(getDaemonThreadCount())} -- This should return the number
1418 of live daemon threads.  A default implementation is provided, based
1419 on @code{getAllThreads()}.
1420 @item @code{(getLockInfo(ThreadInfo))} -- This is an optional native
1421 method called when the VM supports ownable synchronizer usage monitoring
1422 and the user has requested information for a particular thread.  The
1423 supplied @code{ThreadInfo} object should be filled out with an
1424 array of @code{LockInfo} objects, providing details on each lock. 
1425 @item @code{(getMonitorInfo(ThreadInfo))} -- This is an optional native
1426 method called when the VM supports object monitor usage monitoring
1427 and the user has requested information for a particular thread.  The
1428 supplied @code{ThreadInfo} object should be filled out with an
1429 array of @code{MonitorInfo} objects, providing details on each lock. 
1430 @item @code{(getPeakThreadCount())} -- The VM should maintain a record
1431 of the peak number of live threads, and return it when this method is
1432 called.  This is specified as a native method in the reference
1433 implementation.
1434 @item @code{(resetPeakThreadCount())} -- This should reset the record
1435 of the peak number of live threads to the current number of live
1436 threads.  This is specified as a native method in the reference
1437 implementation.
1438 @item @code{(getThreadCount())} -- This should return the number of
1439 live threads.  A default implementation is provided, based on
1440 @code{getAllThreads()}.
1441 @item @code{(getThreadCpuTime(long))} -- This should return the
1442 approximate number of nanoseconds of CPU time the specified thread
1443 has used.  This is an optional native method, which is used by VMs
1444 supporting time monitoring.
1445 @item @code{(getThreadUserTime(long))} -- This should return the
1446 approximate number of nanoseconds of CPU time the specified thread
1447 has used.  This is an optional native method, which is used by VMs
1448 supporting time monitoring.
1449 @item @code{(getThreadInfoForId(long, int))} -- This return an instance
1450 of @code{java.lang.management.ThreadInfo} for the specified thread.
1451 The class includes a private constructor which VMs should use to initialise
1452 it with the appropriate values for the thread.  The second argument
1453 given here specifies the depth of the stack trace supplied on construction
1454 of the instance.  Special values are 0 (return an empty array) and
1455 @code{Integer.MAX_VALUE} (return the maximum depth possible).  This
1456 is specified as a native method in the reference implementation.
1457 @item @code{(getTotalStartedThreadCount())} -- This should return the
1458 total number of threads that have been started by the VM, including ones
1459 that have died.  This is specified as a native method in the reference
1460 implementation.
1461 @end itemize
1462
1463 @node gnu.java.lang.management.VMMemoryMXBeanImpl,gnu.java.lang.management.VMCompilationMXBeanImpl,gnu.java.lang.management.VMThreadMXBeanImpl,gnu.java.lang.management
1464 @subsection @code{gnu.java.lang.management.VMMemoryMXBeanImpl}
1465
1466 The @code{gnu.java.lang.management.MemoryMXBeanImpl} provides an
1467 implementation of the @code{java.lang.management.MemoryMXBean} interface,
1468 and is supported by VM functionality in the form of
1469 @code{gnu.java.lang.management.VMMemoryMXBeanImpl}.  This provides a
1470 series of methods, which should be implemented by the virtual machine
1471 in order to provide the required information for the bean.  Implementing
1472 this bean requires the VM to monitor the levels of heap and non-heap
1473 memory, and provide the number of objects which are eligible for garbage
1474 collection.
1475
1476 The methods are as follows:
1477
1478 @itemize @bullet
1479 @item @code{(getHeapMemoryUsage())} -- This should return
1480 an instance of @code{java.lang.management.MemoryUsage} with
1481 values pertaining to the heap.  A default implementation is
1482 provided, based on @code{java.lang.Runtime}'s methods.
1483 @item @code{(getNonHeapMemoryUsage())} -- This should return
1484 an instance of @code{java.lang.management.MemoryUsage} with
1485 values pertaining to non-heap memory.
1486 @item @code{(getObjectPendingFinalizationCount())} -- Returns
1487 the number of objects which are no longer referenced, and which
1488 will thus be garbage collected on the next run of the garbage
1489 collector.
1490 @item @code{(isVerbose())} -- This should return @code{true}
1491 or @code{false}, depending on whether verbose memory management
1492 output is turned or not, respectively.
1493 @item @code{(setVerbose(boolean))} -- This should allow the
1494 verbose memory management output to be turned on and off.
1495 @end itemize
1496
1497 @node gnu.java.lang.management.VMCompilationMXBeanImpl,gnu.java.lang.management.VMMemoryPoolMXBeanImpl,gnu.java.lang.management.VMMemoryMXBeanImpl,gnu.java.lang.management
1498 @subsection @code{gnu.java.lang.management.VMCompilationMXBeanImpl}
1499
1500 The @code{gnu.java.lang.management.CompilationMXBeanImpl} provides an
1501 implementation of the optional @code{java.lang.management.CompilationMXBean}
1502 interface, and is supported by VM functionality in the form of
1503 @code{gnu.java.lang.management.VMCompilationMXBeanImpl}.  This provides a
1504 single method for returning the number of milliseconds the virtual
1505 machine's Just-In-Time (JIT) compiler has spent compiling.  Even if
1506 a JIT compiler is available and an instance of the bean supplied, this
1507 method is still optional.
1508
1509 Optional support is determined by the following properties:
1510
1511 @itemize @bullet
1512 @item @code{gnu.java.lang.compiler.name} -- This property should
1513 specify the name of the JIT compiler.  Classpath also uses this,
1514 within @code{java.lang.management.ManagementFactory}, to determine
1515 whether a bean should be created.  If this property is set to a
1516 non-null value, a bean will be created and its @code{getName()}
1517 method will return this value.
1518 @item @code{gnu.java.lang.management.CompilationTimeSupport} --
1519 This property should be present if the VM supports monitoring the
1520 time spent compiling.
1521 @end itemize
1522
1523 Time support is implemented by the following method:
1524
1525 @itemize @bullet
1526 @item @code{(getTotalCompilationTime())} -- This should return the
1527 number of milliseconds the JIT compiler has spent compiling.
1528 @end itemize
1529
1530 @node gnu.java.lang.management.VMMemoryPoolMXBeanImpl,gnu.java.lang.management.VMMemoryManagerMXBeanImpl,gnu.java.lang.management.VMCompilationMXBeanImpl,gnu.java.lang.management
1531 @subsection @code{gnu.java.lang.management.VMMemoryPoolMXBeanImpl}
1532
1533 The @code{gnu.java.lang.management.MemoryPoolMXBeanImpl} provides an
1534 implementation of the optional @code{java.lang.management.MemoryPoolMXBean}
1535 interface, and is supported by VM functionality in the form of
1536 @code{gnu.java.lang.management.VMMemoryPoolMXBeanImpl}.  Providing
1537 this interface requires implementing a number of methods for each supported
1538 pool.  These return statistics on memory usage, and, optionally, allows
1539 monitoring of when memory usage exceeds a preset threshold.
1540
1541 Optional support is determined by the following properties:
1542
1543 @itemize @bullet
1544 @item @code{gnu.java.lang.management.CollectionUsageThresholdSupport} --
1545 This property should be present if the VM supports setting a collection
1546 usage threshold and monitoring when it is matched or exceeded.  Collection
1547 usage thresholds are related to the remaining memory usage following a
1548 garbage collection cycle.
1549 @item @code{gnu.java.lang.management.UsageThresholdSupport} --
1550 This property should be present if the VM supports setting a 
1551 usage threshold and monitoring when it is matched or exceeded.  
1552 @end itemize
1553
1554 The methods are as follows (all take a pool name as their
1555 first parameter):
1556
1557 @itemize @bullet
1558 @item @code{(getCollectionUsage(String))} -- Returns a
1559 @code{java.lang.management.MemoryUsage} object, containing the
1560 memory usage statistics following a garbage collection cycle
1561 for the specified pool.  This may also return @code{null} if
1562 the pool isn't an appropriate pool for this particular task.
1563 @item @code{(getCollectionUsageThreshold(String))} -- Returns
1564 the pool's collection usage threshold, if supported.
1565 @item @code{(getCollectionUsageThresholdCount(String))} -- Returns
1566 the number of times the specified pool has matched or exceeded
1567 its collection usage threshold, if supported.
1568 @item @code{(getMemoryManagerNames(String))} -- Returns a list
1569 of names of memory managers which manage the specified pool.
1570 @item @code{(getPeakUsage(String))} -- Returns a
1571 @code{java.lang.management.MemoryUsage} object for the peak
1572 usage level of the specified pool.
1573 @item @code{(getType(String))} -- Returns a string containing
1574 either @code{"HEAP"} or @code{"NON_HEAP"} which indicates the type of
1575 memory used by the specified pool.
1576 @item @code{(getUsage(String))} -- Returns a
1577 @code{java.lang.management.MemoryUsage} object for the current
1578 usage level of the specified pool.
1579 @item @code{(getUsageThreshold(String))} -- Returns
1580 the pool's usage threshold, if supported.
1581 @item @code{(getUsageThresholdCount(String))} -- Returns
1582 the number of times the specified pool has matched or exceeded
1583 its usage threshold, if supported.
1584 @item @code{(isValid(String))} -- Returns true if the pool
1585 is still in use by the virtual machine.
1586 @item @code{(resetPeakUsage(String))} -- Resets the peak usage
1587 levels to the current usage levels for the specified pool.
1588 @item @code{(setCollectionUsageThreshold(String, long))} -- Sets
1589 the pool's collection usage threshold, if supported.
1590 @item @code{(setUsageThreshold(String, long))} -- Sets
1591 the pool's usage threshold, if supported.
1592 @end itemize
1593
1594 @node gnu.java.lang.management.VMMemoryManagerMXBeanImpl,gnu.java.lang.management.VMGarbageCollectorMXBeanImpl,gnu.java.lang.management.VMMemoryPoolMXBeanImpl,gnu.java.lang.management
1595 @subsection @code{gnu.java.lang.management.VMMemoryManagerMXBeanImpl}
1596
1597 The @code{gnu.java.lang.management.MemoryManagerMXBeanImpl} provides an
1598 implementation of the optional @code{java.lang.management.MemoryManagerMXBean}
1599 interface, and is supported by VM functionality in the form of
1600 @code{gnu.java.lang.management.VMMemoryManagerMXBeanImpl}.  Providing
1601 this interface requires implementing two methods (each takes the name
1602 of the manager as the first argument):
1603
1604 @itemize @bullet
1605 @item @code{(getMemoryPoolNames(String))} -- Returns a list of the
1606 memory pools that the manager maintains.  A default implementation
1607 which scans the results of @code{getMemoryManagerNames()} for each
1608 pool is provided.
1609 @item @code{(isValid(String))} -- Returns true if the specified
1610 manager is still valid, i.e., it is still in use by the virtual machine.
1611 @end itemize
1612
1613 @node gnu.java.lang.management.VMGarbageCollectorMXBeanImpl,,gnu.java.lang.management.VMMemoryManagerMXBeanImpl,gnu.java.lang.management
1614 @subsection @code{gnu.java.lang.management.VMGarbageCollectorMXBeanImpl}
1615
1616 The @code{gnu.java.lang.management.GarbageCollectorMXBeanImpl} provides an
1617 implementation of the optional @code{java.lang.management.GarbageCollectorMXBean}
1618 interface, and is supported by VM functionality in the form of
1619 @code{gnu.java.lang.management.VMGarbageCollectorMXBeanImpl}.  Providing
1620 this interface requires implementing two methods (each takes the name
1621 of the garbage collector as the first argument):
1622
1623 @itemize @bullet
1624 @item @code{(getCollectionCount(String))} -- Returns the number of
1625 times the specified garbage collector has run.
1626 @item @code{(getCollectionTime(String))} -- Returns the accumulated
1627 number of milliseconds for which the garbage collector has run.
1628 @end itemize
1629
1630 Note that each garbage collector is also a memory manager, and so an
1631 implementation of the @code{gnu.java.lang.management.VMMemoryManagerMXBeanImpl}
1632 methods for its name should also be provided.
1633
1634 @node java.lang.management, Classpath Callbacks, gnu.java.lang.management, Classpath Hooks
1635 @section @code{java.lang.management}
1636
1637 @code{gnu.java.lang.management} provides the VM interfaces for the GNU
1638 implementations of the management beans.  
1639
1640 @menu
1641 * java.lang.management.VMManagementFactory::
1642 @end menu
1643
1644 @node java.lang.management.VMManagementFactory,,,java.lang.management
1645 @subsection @code{java.lang.management.VMManagementFactory}
1646
1647 This VM interface provides the names of the memory pools, memory managers
1648 and garbage collectors for use by the @code{java.lang.management.ManagementFactory}
1649 in creating lists of appropriate beans for these types of managed object.
1650
1651 The methods are as follows:
1652
1653 @itemize @bullet
1654 @item @code{(getMemoryPoolNames())} -- Returns a list of the names
1655 of the current memory pools in use by the virtual machine.
1656 @item @code{(getMemoryManagerNames())} -- Returns a list of the names
1657 of the current memory managers in use by the virtual machine.  This
1658 should not include those that are also garbage collectors.
1659 @item @code{(getGarbageCollectorNames())} -- Returns a list of the names
1660 of the current garbage collectors in use by the virtual machine.
1661 @end itemize
1662
1663 @node Classpath Callbacks, , java.lang.management, Classpath Hooks
1664 Some of the classes you implement for the VM will need to call back to
1665 package-private methods in Classpath:
1666
1667 @itemize @bullet
1668 @item @code{java.lang.ThreadGroup.addThread(Thread)}
1669 Call this method from @code{Thread} when a new @code{Thread} is created, to add it to
1670 the group.
1671
1672 @item @code{java.lang.ThreadGroup.removeThread(Thread)}
1673 Call this method from @code{Thread} when a @code{Thread} is stopped or destroyed.
1674
1675 @item @code{gnu.java.lang.management.MemoryMXBeanImpl.fireThresholdExceededNotification(String, long, long, long, long)}
1676 If the monitoring of memory usage thresholds is supported, this method
1677 should be called when the normal usage of a memory pool crosses the
1678 threshold, in order to emit a notification.  Another notification
1679 should not be emitted until there is an intermittent period where the
1680 usage is again below the threshold.  The parameters are the memory
1681 pool name, the usage levels (init, used, committed and max) and the
1682 number of times the threshold has been crossed.
1683
1684 @item @code{gnu.java.lang.management.MemoryMXBeanImpl.fireCollectionThresholdExceededNotification(String, long, long, long, long)}
1685 If the monitoring of memory usage thresholds is supported, this method
1686 should be called when the usage of a memory pool after a garbage
1687 collection cycle crosses the threshold, in order to emit a
1688 notification.  Another notification should not be emitted until there
1689 is an intermittent period where the usage is again below the
1690 threshold.  The parameters are the memory pool name, the usage levels
1691 (init, used, committed and max) and the number of times the threshold
1692 has been crossed.
1693
1694 @end itemize
1695
1696 @node VM Hooks, JNI Implementation, Classpath Hooks, Top
1697 @comment node-name, next, previous, up
1698 @chapter VM Hooks
1699
1700 VMs need to do some dirty work; there are some things in the VM that
1701 unfortunately are dependent on the internal structure of various
1702 classes.  This is a guide to all of the things the VM itself needs to
1703 know about classes.
1704
1705 Some of the core classes, while being implemented by GNU Classpath,
1706 provide space for state (in the form of a @code{vmdata} object) to be
1707 stored by the VM, and can not be constructed normally.
1708
1709 @itemize @bullet
1710 @item java.lang.Class
1711 @item java.lang.ClassLoader
1712 @end itemize
1713
1714 The default implementations of some VM classes also follow this methodology,
1715 when it is intended that most VMs will keep the default.
1716
1717 @itemize @bullet
1718 @item java.lang.VMThread
1719 @item java.lang.VMThrowable
1720 @end itemize
1721
1722 Several core classes must be completely implemented by the VM for Classpath to
1723 work, although reference implementations are provided.  These classes are:
1724
1725 @itemize @bullet
1726 @item java.lang.reflect.Constructor
1727 @item java.lang.reflect.Method
1728 @item java.lang.reflect.Field
1729 @end itemize
1730
1731 The following issues are of note;
1732
1733 @itemize @bullet
1734 @item @code{java.lang.Class} @*
1735 The GNU Classpath implementation of @code{java.lang.Class} provides an
1736 object for storing the internal state of the class maintained by the VM.
1737 This is the only known place where this matters.  The class is
1738 constructed with this data by the VM@.  Some VMs do not create the
1739 @code{Class} object at the point where the class is defined; instead,
1740 they wait until a @code{Class} object is actually used.
1741
1742 @item Array Classes @*
1743 When you are creating an array class, you should set the
1744 @code{ClassLoader} of the array class to the @code{ClassLoader} of its
1745 component type.  Whenever you add a class to a @code{ClassLoader}, you
1746 need to notify the @code{ClassLoader} and add the new @code{Class} to
1747 its internal cache of classes.  To do this, call
1748 @code{ClassLoader.addVMCreatedClass(Class)}.  @emph{Note: this is
1749 written in anticipation of 1.2 support and does not apply just yet.}
1750
1751 @item Primordial Class Loader @*
1752 When the primordial class loader loads a class, it needs to tell
1753 Classpath what it has done in order for security stuff to work right.
1754 To do this, call the static method
1755 @code{ClassLoader.newPrimordialClass(Class)}.
1756
1757 Even the first few core classes need to do this; in order to do it,
1758 simply call this method @emph{after} the initial class loading has been
1759 done.  No harm will come, as long as you follow the guidelines in the
1760 @pxref{Initialization} section.
1761
1762 @emph{Note: this is written in anticipation of 1.2 support and does not
1763 apply just yet.}
1764
1765 @item Top-level Exception Handler @*
1766 Exceptions take care of themselves in Classpath; all you need to do in
1767 the top-level exception handler is call @code{Throwable.printStackTrace()}.
1768
1769 @item Security and Traces @*
1770 There will eventually be a feature in the 1.2 security that keeps the
1771 @code{AccessController} from having to evaluate @emph{all} of the
1772 @code{ProtectionDomain}s every time a security check is made.  I think a common
1773 case is a single method doing a lot of things that require security
1774 checks.  However, I don't want to bog down the method stack too much, so
1775 this feature of the VM will have the @code{AccessController} for a thread
1776 calling out to the VM to tell it how high it was on the stack when it
1777 made the last security request.  Every time the stack goes lower than
1778 that number, the VM will decrement the number.  The @code{AccessController}
1779 will remember what the accumulated protection status was at every stack
1780 level (an @code{AccessControlContext}) and use that aggregated information to
1781 do the check.  I am not sure, however, whether the savings are
1782 substantial enough to outweigh the integer check and set after every
1783 method call.  I will investigate.
1784
1785 @item Threading @*
1786 I figured I'd put this here because a VM guy might be wondering about it.
1787 We implement @code{ThreadGroup}, but that class is almost entirely
1788 VM-independent.  The root @code{ThreadGroup}, a static field called
1789 @code{ThreadGroup.root}, should be initialized by Classpath, but if you wish to
1790 reinitialize it yourself, there should be no harm.
1791
1792 @end itemize
1793
1794 @node JNI Implementation, JVMTI Implementation, VM Hooks, Top
1795 @comment  node-name,  next,  previous,  up
1796 @chapter JNI Implementation
1797
1798 Classpath comes with its own implementation of @file{jni.h}.  This
1799 file can be customized by the VM in a few ways, by defining macros
1800 that affect the interpretation of the file.  These macros are all
1801 intended for use by a VM which uses GNU Classpath and which wants to
1802 use a single copy of @file{jni.h} for both internal and external use.
1803
1804 @itemize @bullet
1805 @item _CLASSPATH_VM_JNI_TYPES_DEFINED
1806 Some VMs like to define JNI ``object'' types in a special way.  If
1807 this macro is defined, the Classpath @file{jni.h} will avoid defining
1808 these types.  By default, these types are defined in @file{jni.h}.
1809 The full list of types and macros treated this way is: @samp{jobject},
1810 @samp{jclass}, @samp{jstring}, @samp{jthrowable}, @samp{jweak},
1811 @samp{jarray}, @samp{jobjectArray}, @samp{jbyteArray},
1812 @samp{jshortArray}, @samp{jintArray}, @samp{jlongArray},
1813 @samp{jbooleanArray}, @samp{jcharArray}, @samp{jfloatArray},
1814 @samp{jdoubleArray}, @samp{JNIEnv}, @samp{JavaVM}, @samp{JNI_TRUE}
1815 (macro), @samp{JNI_FALSE} (macro).
1816
1817 @item _CLASSPATH_VM_INTERNAL_TYPES_DEFINED
1818 If the VM has its own definitions for @samp{jfieldID} and
1819 @samp{jmethodID}, then it should define this macro.  Otherwise,
1820 @file{jni.h} will provide definitions for these types.
1821
1822 @item _CLASSPATH_JNIIMPEXP
1823 Three functions -- @samp{JNI_GetDefaultJavaVMInitArgs},
1824 @samp{JNI_CreateJavaVM}, and @samp{JNI_GetCreatedJavaVMs} -- must be
1825 marked as @samp{JNIIMPORT} when seen by user code, but most likely
1826 should be marked as @samp{JNIEXPORT} when defined in the VM
1827 implementation.  This macro can be defined to one or the other by the
1828 VM as appropriate.  If this macro is not defined, it defaults to
1829 @samp{JNIIMPORT}.
1830
1831 @item _CLASSPATH_JNIENV_CONTENTS
1832 A VM can add fields to the @samp{JNIEnv} structure by defining this to
1833 be a sequence of field declarations.
1834
1835 @end itemize
1836
1837 @node JVMTI Implementation, Miscellaneous VM Requirements, JNI Implementation, Top
1838 @comment node-name, next, previous, up
1839 @chapter JVMTI Implementation
1840
1841 Classpath comes with its own implementation of @file{jvmti.h}.  This
1842 file can be customized by the VM in a few ways by defining macros that
1843 affect the interpretation of the file.  These macros are all intended
1844 for use for use by a VM which uses GNU Classpath and which wants to
1845 use a single copy of @file{jvmti.h} for both internal and external use.
1846
1847 @itemize @bullet
1848 @item _CLASSPATH_VM_JVMTI_TYPES_DEFINED
1849 Some VMs like to define JVMTI ``object'' types in a special way.  If
1850 this macro is defined, the Classpath @file{jvmti.h} will avoid defining
1851 these types.  By default these types are defined in @file{jvmti.h}.  
1852 The full list of types and macros treated this way is: @samp{jthread},
1853 @samp{jthreadGroup}, @samp{jlocation}, and @samp{jrawMonitorID}.  By
1854 default @samp{jrawMonitorID} is defined as an opaque pointer which
1855 must be defined by the VM.
1856
1857 @item _CLASSPATH_JVMTIENV_CONTENTS
1858 A VM can add fields to the @samp{jvmtiEnv} structure by defining this
1859 to be a sequence of field declarations.
1860
1861 @end itemize
1862
1863 @node Miscellaneous VM Requirements,  , JVMTI Implementation, Top
1864 @comment  node-name,  next,  previous,  up
1865 @chapter Miscellaneous VM Requirements
1866
1867 Classpath places a few requirements on the VM that uses it.
1868
1869 @menu
1870 * JNI Version::                 
1871 * VM Threading Model::          
1872 * Boot Library Path Property::
1873 @end menu
1874
1875 @node JNI Version, VM Threading Model, Miscellaneous VM Requirements, Miscellaneous VM Requirements
1876 @comment  node-name,  next,  previous,  up
1877 @section JNI Version
1878
1879 Classpath currently uses only JNI 1.1, except for one JNI 1.2 function
1880 in the JNI Invocation API: GetEnv().  And GetEnv() is only used in the
1881 now deprecated ``portable native sync'' code.
1882
1883 A future direction will probably be to require that all VMs provide
1884 JNI 1.2.  If this poses problems, please raise them on the classpath
1885 mailing list. 
1886
1887 @node VM Threading Model, Boot Library Path Property, JNI Version, Miscellaneous VM Requirements
1888 @comment  node-name,  next,  previous,  up
1889 @section VM Threading Model
1890
1891 VM authors can implement a number of different threading models. When
1892 native code is also threaded there is the potential for one threading
1893 model to deadlock the other. The
1894 @uref{http://java.sun.com/docs/books/jni/html/other.html#29406,Java
1895 Native Interface Programmer's Guide and Specification} suggests
1896 consulting VM documentation in such situations. Classpath uses
1897 existing libraries, for example the AWT peers can use the GTK+
1898 graphics library. As these libraries assume a different threading
1899 model, there is the potential for the native code to deadlock a VM.
1900
1901 The different threading models available to a VM author are:
1902 @enumerate
1903 @item
1904 @i{Native threads}: Map a Java thread to an underlying operating system
1905 thread (normally a POSIX compatible pthread). This approach reduces
1906 the potential for deadlock as there is only one thread scheduling
1907 mechanism.
1908 @item
1909 @i{Green threads 1}: Green threads are threads scheduled by the VM,
1910 typically by switching swapping registers. In early VMs green threads
1911 were seen as advantageous as they didn't require the operating system
1912 to reschedule, save and swap all of a threads registers. The green
1913 thread 1 model switches thread on an externally created event, such as
1914 a timer interrupt. An example of a VM using this approach is Kaffe
1915 configured with its jthreads model.
1916 @item
1917 @i{Green threads 2}: The essential difference with this model is to
1918 not switch threads on an event, but at fixed points in the code being
1919 executed by the VM@. Points chosen could be backward branches (loops)
1920 or method calls. This approach can be advantageous to nonconservative
1921 garbage collectors, as non-running threads would be at known points
1922 and can have fixed register maps. It can also reduce the number of
1923 registers it is necessary to swap when switching threads.
1924 @item
1925 @i{M:N threading}: a flaw to green threading is that it is unable to
1926 use multiple processors. @i{M}:@i{N} threading fixes this problem by
1927 running groups of green threads on multiple underlying native
1928 threads. An example of a VM using this approach is the Jikes RVM,
1929 which uses @i{M}:@i{N} threading combined with the green thread 2
1930 model.
1931 @end enumerate
1932
1933 An example of the problem of mixing threading models is:
1934 @itemize @bullet
1935 @item
1936 A Java thread calls a native method. The native method acquires a lock.
1937 @item
1938 The native method calls back into the VM.
1939 @item
1940 An event triggers the VM to reschedule the currently running thread.
1941 @item
1942 A new VM thread, executing on the same underlying native thread, calls
1943 a native method.
1944 @item
1945 The native method tries to acquire the lock already acquired earlier. As
1946 the lock is busy the thread waits and allows the operating system to
1947 reschedule native threads.
1948 @item
1949 The operating system reschedules the VM thread again, but the lock is
1950 still busy and in some threading models will remain busy forever
1951 (the VM is deadlocked).
1952 @end itemize
1953
1954 VMs that don't use the underlying operating system thread scheduling
1955 mechanism need to avoid deadlock. One now deprecated approach was to
1956 build Classpath and VMs on top of a wrapper thread library (aka
1957 portable native sync). The wrapper thread library used was GLIB's
1958 @dfn{gthreads}. This approach has been deprecated because:
1959 @enumerate
1960 @item
1961 The wrapper library is only in use by some native libraries. For
1962 example, GTK+ uses the gthread library but QT does not.
1963 @item
1964 The wrapper library can't be in use prior to the VM starting as the VM
1965 must replace the wrapper libraries functions with its own. This
1966 prevents the VM from running as a plugin in an application that
1967 already uses the wrapper library.
1968 @end enumerate
1969
1970 An alternative approach is for the VM to detect deadlocked native code
1971 and swap Java threads off of that native thread. The VM can't,
1972 however, swap two blocked native threads that are potentially
1973 deadlocking each other on a lock. The lock will be associated with the
1974 native thread. To prevent this from happening the VM must hijack
1975 functions that operate on locks. This is done by redefining the lock
1976 functions inside the VM and configuring the linker so that it uses the
1977 VMs symbol in preference to that of the external thread support
1978 library. The VM's lock function can then reschedule Java threads if it
1979 must wait for the lock.
1980
1981 @node Boot Library Path Property,  , VM Threading Model, Miscellaneous VM Requirements
1982 @comment  node-name,  next,  previous,  up
1983 @section Boot Library Path Property
1984
1985 As of GNU Classpath 0.15 a system property named @code{gnu.classpath.boot.library.path}
1986 can be set by the VM to specify the directories which contain GNU Classpath's native
1987 libraries. Usually this value is given at configuration time and is then hardcoded
1988 in the VM@. However for development purposes it is handy to switch to another installation
1989 by overriding the properties' value on the command line.
1990
1991 A VM that does not support this feature can simply ignore the property.
1992
1993 For compatibility reasons we suggest to set the default value of @code{java.library.path}
1994 to the value of the @code{LD_LIBRARY_PATH} environment if it exists on your platform.
1995
1996 @bye
1997
1998
1999