Ulrich Kunitz wrote:
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.
Ugh. Those papers perhaps are not as clear as they could be. I've
written a separate email saying a little more about how vmmagic works.
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.
I don't know what the performance impact is of mmaping a monolithic boot
image versus incrementally loading it. Demand loading could lead to a
much smaller memory footprint though. There are quite a lot of
different ways of doing it, some of which would depend on the code being
relocatable. I think this is an interesting space to explore,
particularly if we want to try to cover the gamut from embedded devices
to servers.
I assume you It would not be terribly hard to do a lot of precompilation
(think building .so's), and then to lazily bring precompiled methods
into the VM. There are a number of issues though
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.
I agree.
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...
Possibly, but that is not our experience. In MMTk we carefully avoid
array bounds checks interface calls and write barriers. When we rework
the performance critical elements (barriers, allocation, etc), we
carefully measure the performance and typically examine the compiled
instruction sequence. If it looks like it needs improvement we either
adjust our implementation or improve the compiler ;-)
--Steve
