harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ulrich Kunitz <k...@deine-taler.de>
Subject Re: Terminology etc
Date Tue, 24 May 2005 21:55:27 GMT
Steve, this "clarification of terminology" helped me a lot to understand
your approach better. As Java-in-C camper I can even see now the
advantages in the approach. But just let me add my 2 cents of pretty
wild ideas.

Having read your MMTk papers, it appears to me that the required
JAVA extensions look a little bit like parts of P/Invoke* of
Microsoft's Common Language Runtime. (P/Invoke is a convenient way
to call C functions in the VM without the need to program glue
code in C. It must allow memory access over pointers via a
Marshal class. Security fanatics should recognize, that such a
class can be implemented for Java using JNI.) A comparable
mechanism in Harmony would not only be useful for the Java garbage
collector but also the OS interface. 

Maybe it would be possible to extend the boot image approach to
some kind of cached images of Java classes and packages, This
would require some ELF-like format for compiled Java code. Such a
feature might reduce the startup times of applications like
Eclipse a lot. If I'm not misinformed the gcj developers want to
build something like this.

IMHO a self-hosting VM has the advantage, that performance is
under your own control. Code in C will always depend on the
optimizations provided by the C compiler being used. Additionally
all the debugging/profiling/management code can be written in Java
and can use the large Java class library. The class library itself
provides also the platform abstractions, which will be needed to
support Windows and POSIX platforms with the same code.

But it might still be that C-implemented modules (particularly the
GC) are faster than their Java-implemented counterparts, because
they ignore array-index-checking, don't need write barriers and
interface calls, etc... One could follow the strategy, that
modules must support Java interfaces but might be implemented in
C. This strategy would bring us back to an design that doesn't
mandate which language has to be used to implement a certain


View raw message