harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Blackburn <Steve.Blackb...@anu.edu.au>
Subject Re: Terminology etc
Date Wed, 25 May 2005 03:07:40 GMT
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 ;-)


View raw message