harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Tromey <tro...@redhat.com>
Subject Re: [arch] Interpreter vs. JIT for Harmony VM
Date Wed, 21 Sep 2005 17:12:42 GMT
>>>>> "Michael" == Michael Haupt <mhaupt@gmail.com> writes:

Michael> couldn't startup time be increased by caching native code versions of
Michael> methods somewhere on the hard disk and loading instead of compiling
Michael> them every time the VM is started up?

Yeah, startup can be improved this way.  In fact doesn't Sun's 1.5 do
this?  (I don't pay that close attention.)  And of course gcj does.

There's a tension here between startup time and some other factors.
If you want to dynamically recompile core library code then it seems
like you have to write out some JIT state as well as the object code.

If you want to get the benefits of shared libraries (which may be a
win in desktop-y situations but may not be in, say, web server
situations), then if you do recompile then you at least partially
forgo any benefits of shared libraries.  And, in this case you are
probably also looking at generating PIC code.

I'm not sure, but if you write out precompiled code perhaps it always
must be PIC on systems that randomize the memory map.

Doing this for arbitrary libraries and not just the core is a bit
trickier.  Luckily we've got a lot of experience with that in gcj :-)

One way to deal with some of the development issues here, in a Harmony
context, would be to hide them behind the veil of pluggable execution
engines.  I imagine that if we try to solve all the problems up front
we will just get stuck.

Michael> Sorry for being off-topic,

IMO not offtopic as we're discussing what to do, and this is an option.

Tom

Mime
View raw message