HI ALl,
As u propose the code as below, some what like a JNI. If we need it,
better to port decaf to JNI compatible one. :P
Regards,
Hilary
>
> 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
_______________________________________________
Kernel maillist - [EMAIL PROTECTED]
http://jos.org/mailman/listinfo/kernel
