Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Message-ID: <4331924C.5080701@sourcelabs.com>
Date: Wed, 21 Sep 2005 10:03:08 -0700
From: will pugh <willpugh@sourcelabs.com>
User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716)
MIME-Version: 1.0
To: harmony-dev@incubator.apache.org
Subject: Re: [arch] Interpreter vs. JIT for Harmony VM
References: <7cbeaf9e050921021216b4e6a2@mail.gmail.com>
	 <F6296D55-CC23-485E-B3A5-77C9F4087C14@apache.org>
	 <m3aci61mnk.fsf@localhost.localdomain>	 <43317C6B.8080100@sourcelabs.com>
 <b1ba078405092108472ca91379@mail.gmail.com>
In-Reply-To: <b1ba078405092108472ca91379@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Short answer is "yes", but there are a few issues you need to take into 
account.  You need to deal with:

  1)  Changed classes/jars.  Need to be able to detect when you have a 
new copy of a jar or a classfile
  2)  Instrumented code.  If you are in a situation where code is 
getting instrumented (JVMTI, Apps using BCEL, etc) you need to make sure 
not to cache the intrsumented code if it is at all dependent on runtime 
parameters or environmental parameters
  3)  Custom Classloaders.  Hard to know what they will load and from where.
  4)  Security concerns.  Can someone get at the JITed code on disk? (In 
general this is probably not too big a deal, since given disk access 
someone could hack any of your images.  You just want to make sure 
people recognize distributing cached images is not really as safe as 
distributing Java)


If you're just looking to make startup fast, you can cache purely on a 
per class level where you simply ignore the first three problems and 
just cache classname, MD5 hash and native code.  Then as a class is 
being loaded verify the MD5 hash and pull the image from disk is that 
you need to make sure to have no optimizations that take into account 
anything else or have some kind of dependency tree for them.  E.g.  If 
class A uses class B, and we inline a number of the methods where classA 
calls into classB, then cache these to disk.   Then if class B changes, 
class A needs to know that it needs to be rebuilt as well (although this 
may not be too hard since you probably need to cache that info as well. 
. .).

If you want to cache to allow long running optimizations to be preserved 
it's a bit trickier because you need to deal with issues 1-3 above.

    --Will

Michael Haupt wrote:

>Hi,
>
>On 9/21/05, will pugh <willpugh@sourcelabs.com> wrote:
>  
>
>>  2)  The FastJIT needs to be Fast!  Otherwise, you run the risk of
>>people not wanting to use it for IDEs and Apps because the startup time
>>is too slow.
>>    
>>
>
>couldn't startup time be increased by caching native code versions of
>methods somewhere on the hard disk and loading instead of compiling
>them every time the VM is started up?
>
>Sorry for being off-topic,
>
>Michael
>  
>