> 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.
Specifically, there could be the interpreter and bytecode
internalization* in one module, and the VM-specific code in another module
or set of modules; ditto the native code for the class library to be
used. My specific concern for JNI is that class library native code that
the maintainers of the class library write in JNI (to maintain VM
independence). It would be /very/ nice not to add another Java class
library to the mix...
> 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.
And that's the key -- for JVM-specific classes, it's fine to use
JVM-specific methods (duh.) But this mechanism doesn't extend to extant
native libraries which use JNI.
> Thanks for the clarification. I'd like to continue working on Kore/BCNI.
And I will be more than happy to slurp the BCNI code at the
appropriate point -- and the Kore code if you can get it and its libraries
working before I get classpath working. Happy hacking!
> 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?).
Yes. That's why the current implementation of 'init' sits in an
infinite loop. This may be changed so that some VMs will continue to
exist for daemon threads like the TCP/IP stack -- things at the system
level. (On the other hand, decaf doesn't make an explicit distinction
between daemon and regular threads, so I'll have to look at the specs and
see what to do. The technical behavoir of decaf is to terminate when
(a) there are no unserviced interrupts pending, (b) there are no
unserviced notifications pending, and (c) there are no threads in the
active queue. This will probably create problems for event-based apps
(most of them!) unless they also leave a busy-waiting thread lying
around, so I'll look at that before I CVS the new code. Thanks for
bringing it to my attention.)
> 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?
Yes. If the initialization code for getting the 'Kernel'
(jjmachine *) weren't platform-specific, decaf_main() could be the C++
entry point for jJOS/decaf.
In general, I don't see any particular technical difficulty to
maintaining a decaf distribution as a system-wide 'libjvm' type of thing,
and with a bit of work, it should be able to work much like TCL. I've
(obviously!) got other things to work on right now, but this could be an
interesting project.
-_Quinn
* Note that the bytecode /fetching/, as per the classloader spec, can be
done by just about anything -- and there's no reason to suppose that the
primordial classloader couldn't also be provided by the application,
though I'm not going to go out of my way to allow that right now.
_______________________________________________
Kernel maillist - [EMAIL PROTECTED]
http://jos.org/mailman/listinfo/kernel
