From: Archie Cobbs (archie@whistle.com)
Date: Wed Sep 16 1998 - 17:37:44 EDT
Tim Wilkinson writes:
> > Ideally, clearly defined API's would allow GCJ and Kaffe to continue
> > to develop semi-independently yet still remain compatible with an
> > already agreed-upon common interface.
> >
> > Kaffe+GCJ+Klasses.jar+Etc is already starting to get too monolithic.
>
> There's an attempt by the Classpath mob to do something like this by defining
> VMAPI so their classes are potable to any JVM supporting it. I don't know ho
> how far they've got with this idea as yet.
Yeah... of course the native mehods are the "easy" part of the API..
> However, as regards GCJ, it'd be difficult to generate GCJ code
> which would run on any VM without wasting memory. GCJ generates
> internal class, method and field records which should match those
> of the hosting VM so you can simply load in the shared library and
> off you go - no parsing and wasting of memory that takes. Of course
> you could parse these structures and convert them but that defeats
> at least some of GCJ's purpose (though not all of course). I've
> had to make a few patches go my GCJ version so these internals
> match Kaffe's internals (it's close 'cause Cygnus are using an old
> version of Kaffe with a few minor changes).
Agreed, the interface would have to define all of these structures, etc.
It would be a very 'tight' interface.
> I keep thinking about pulling out the execution engines from the
> runtime (you can kind of doit with the Custom edition but it's not
> all there yet).
Cool..
> One of the major problems here is mixing execution engines. The
> JIT and GCJ are easybecause both use standard C calling convention.
> However, mising the interpreter with these is hard - especially to
> do it efficiently. The obvious thing to do is to make the interpreter
> use C calling convention too, but that'll take quite a rewrite of
> how it is now (which might not be a bad idea anyhow).
The interpreter is expected to be slow anyway, so it's OK if
there's more overhead.. :-)
> > Kaffe executable
> > ----------------
> > - Similar to the existing "Kaffe" program, just links with the JVM
> > shared library and runs the class's main().
> > - Command line flags:
> > -jit Causes it to link in the Kaffe JIT engine shared library
> > and register it as the internal class handler.
> > -gcj Causes it to link in the GCJ JIT engine shared library
> > and register it as the internal class handler.
> > -precomp Simply loads and pre-compiles all classes referenced
> > transitively by the main() class. Doesn't actually run
> > anything, just fills the cache.
> > -cache Specify directory for cached/pre-compiled binary class files
> >
> > Thoughts?
>
> This would be really nice to do, though I think the --precomp option
> might be difficult to do well (I suppose you can just follow all
> found class and method references - but it doesn't handle reflection).
> Since GCJ is now available I also wonder if it's worth making the
> JIT code saveable - personally I'd compiled all my common classes
> (Klasses.jar, pizza.jar) with GCJ, install them and JIT the rest.
How does GCJ handle native methods? Presumably, it just leaves them
alone and lets the VM handle calling them when the time is right.
If this is the case, reflection is not a problem for --precomp
because it just represents more native methods. As long as the
VM/native reflection code can interpret compiled class files in
order to pull out the reflection info, then it should work...
The underlying concern I have with all of this is that there is a
lot of good stuff to be done, and it would be a shame for it to be
done in a sub-optimal way just because the kaffe people and the
Cygnus people never talked to each other or something. Of course
it's not really like that, but there are some deep and serious
design issues, and these issue will require a lot of communication
and contribution from both 'camps' in order to solve properly, it
seems to me.
Maybe the first step should be a clear statement of design *goals*...
-Archie
___________________________________________________________________________
Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:56:57 EDT