At 08:56 PM 2/29/00 -0500, "Todd L. Miller" <[EMAIL PROTECTED]> wrote:
>> Question: What is the status of decaf/classpath?
>
> decaf is currently under extremely heavy development at my
>top-secret research labs located on the seafloor just outside of
>Norfolk. Unfortunately, their fiber was cut during a Navy training
>excercise and they won't be able to code to the CVS for at least another
>week.
>
> More seriously, I'm working on a total rewrite of the common/decaf
>code, designed so that the VM-specific native code required to run
>classpath will be as elegant and efficient as possible. I'm giving
>consideration to writing the native code calls & lookups toward ERIC,
>specifically its SharedLibrary class (I don't recall if you've posted the
>source or not). Insulating decaf from how it fetches its native code is a
>good idea; that the native code for VM-specific classes (and /all/ native
>code on the host) will be linked in statically shouldn't prove to be too
>much of a problem, right?
Oh, wow. I hadn't thought of that. If we have a SharedLibrary interface in
C++, we can have a corresponding shared library factory for JVM-specific
"classes". I was thinking of decaf as one big shared library; but no! it
can be more modular.
When compiled to a shared library, I can invoke the decaf virtual machine
through a function like this:
const char *libname = "decaf";
void example() {
SharedLibrary lib = createSharedLibrary( libname );
decaf_main = lib.getMethod( "decaf_main" );
decaf_main( argc, argv, Kernel *k );
}
To extend it as you describe, we *could* get a shared library for "classes"
within decaf virtual machine through a similar function:
const char *libname = "decaf";
const char *classname = "java.lang.Object";
void example() {
SharedLibrary lib = createSharedLibrary( libname );
void *(*getNativeClass)(const char *);
getNativeClass = lib.getMethod( "getNativeClass" );
SharedLibrary o = getNativeClass( classname );
jclass *(*object_getClass)(jobject *);
object_getClass = o.getMethod( "getClass" );
jclass v = object_getClass( jobject );
}
Of course, getNativeClass() is JVM-specific. For decaf, it can return an
instance of SharedLibrary appropriate to the requested class. Using the
existing decaf mechanism to bind methods to machine code, each decaf
sublibrary might return pointers to methods of a single class.
I would prefer to Kore-like approach used in the Alt packages. It uses a
shared library for each *package*, instead of for each class. While both
are functionally equivalent, one shared library per package is simpler.
const char *libname = "decaf";
const char *classname = "java.lang";
void example() {
SharedLibrary lib = createSharedLibrary( libname );
void *(*getNativeClass)(const char *);
getNativeClass = lib.getMethod( "getNativeClass" );
SharedLibrary lang = getNativeClass( classname );
jclass *(*object_getClass)(jobject *);
object_getClass = lang.getMethod( "Object.getClass" );
jclass v = object_getClass( jobject );
}
At the next level, the above code *could* be reduced using a multi-stage
factory to create a shared library:
const char *libname = "decaf:java.lang";
void example() {
SharedLibrary lang = createSharedLibrary( libname );
jclass *(*object_getClass)(jobject *);
object_getClass = lang.getMethod( "Object.getClass" );
jclass v = object_getClass( jobject );
}
All features of the shared library factory can be delegated to a
platform-specific implementation of createSharedLibrary(). Or, a
platform-specific behavior can be implemented as plug-ins.
Note: Method names are mapped to machine code by each shared library. The
name of a Java native method can be *anything*; it does not have to use the
JNI naming convention. In C++, I want a method called object_getClass
instead of a method called Java_java_lang_object_getClass.
>> Is it possible to develop decaf so that it is compatible with Kore *and*
>> JDK 1.1.6 *and* classpath? We might have concurrent "subplatforms" defined
>> decaf. By changing the list when decaf binds machine code to native
>> methods, decaf works across all versions of Java.
>
> This should be possible. I will not, however, be providing
>support for anything aside from classpath. Kore should be fairly simple
>for someone to add; JDK 1.1.x will be very difficult, unless Kaffe (et
>al) have a remarkably clean JVM/VM class separation that allows us to look
>at their source to derive what, exactly, Sun's native code is supposed to
>be doing.
Thanks for the clarification. I'd like to continue working on Kore/BCNI.
> Just as note -- even if we can link and load classpath libraries,
>we can't do anything useful with them yet, because decaf does not
>currently (and may not ever) support JNI. It would seem advisable to
>develop dynamic library support for the i386 build (or borrow it from
>somewhere else) for fairly straight-forward reasons about driving the
>hardware (especially hot-pluggable h/w), but I'm not quite so sure that
>JNI is a good idea. In certain locations (e.g. h/w) we must use native
>code until such a time that decaf can run a java device driver fast enough
>to handle h/w timeouts and buffers, etc (and even then, it's probably wise
>to stick with native drivers in most cases), but no user-level task should
>require native code aside from (possibly) driver support.
The SharedLibrary mechanism shown above might be simpler than JNI. I prefer
BCNI over JNI. decaf works without JNI. To start decaf after its a shared
library, any program can call decaf_main() to start the virtual machine.
decaf returns from decaf_main() after all of non-daemon threads are
complete (doesn't it?).
The interface between jJOS and decaf (and any other virtual machine for
that matter) might be reduced to an interface like that of a command line,
similar to the java tool. A caller must assemble argv and pass it to
decaf_main().
void decaf_main( int argc, char *argv[], Kernel *k );
This is what jJOS does, isn't it?
_______________________________________________
Kernel maillist - [EMAIL PROTECTED]
http://jos.org/mailman/listinfo/kernel
