harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nick Lothian" <nloth...@educationau.edu.au>
Subject RE: Introduction, and a question
Date Wed, 18 May 2005 01:05:30 GMT
Some of IBM's JDKs cache JIT'ed code on some platforms; see http://www-128.ibm.com/developerworks/java/library/j-shared/
for details.

That link talks about some of the problems. It isn't a trivial problem by any means. IBM's
implementation uses a "Master VM" and "Worker VMs" that share system classes in the system

NET has a program called "NGEN" which does something like this. It pre-compiles MSIL to native
machine code. Unfortunate using NGEN precludes using it with a JIT compiler as well - once
NGEN'ed the VM does no further optimization to that assembly (although sometimes the NGEN'ed
assembly will be ignored and the VM will fall back a conventional implementation). The lack
of dynamic optimization means that in many circumstances NGEN'ed code will run slower than
if NGEN hadn't been used.

I believe that Microsoft recommended NGEN mostly for applications where start-up time is important.


> This sounds like how java works under OS X.
> Newbie question: What is to stop us from caching JITed code?  
> .NET/ mono does this as far as I know?
> Stuart
> On 17 May 2005, at 06:05, Nick Lothian wrote:
> >>
> >> El lun, 16-05-2005 a las 16:08 +0530, Subramanian, Sundar escribió:
> >> (...)
> >>
> >>> I guess what Brad is asking is for a snapshot of the state of JVM.
> >>> This
> >>> would be really useful to migrate stuff from one environment to 
> >>> another preserving the underlying state.
> >>>
> >>
> >> I have mixed feelings about having a "save image" __a la__ 
> Smalltalk, 
> >> if this is what you are meaning. While delivering an image looks 
> >> tempting, state gets corrupt in unpredictable ways, and 
> having ways 
> >> to track changes becomes a nightmare.
> >>
> >> The Smalltalk community has worked hard in this (hard) 
> problem, but 
> >> I'm still not sure if it would make sense in the java 
> world. Java is 
> >> a system-oriented language, and the ability to save the whole VM 
> >> state and recover from this saved image would bring additional 
> >> constraints to the Virtual Machine implementation. For instance, 
> >> machine specific JIT code should be invalidated upon save, 
> negating a 
> >> substantial part of the advantages of a saved image 
> (faster startup).
> >>
> >> This said, if VM implementors out there find easy ways to 
> meet these 
> >> constraints w/o burdening runtime or memory requirements, 
> it could be 
> >> an area for experimenting.
> >>
> >>
> >
> > This looks like it would be related to the stuff Sun has done with 
> > class data sharing in the 1.5 JVMs:
> >
> > "When the JRE is installed on 32-bit platforms using the 
> Sun provided 
> > installer, the installer loads a set of classes from the system jar 
> > file into a private internal representation, and dumps that 
> > representation to a file, called a "shared archive". Class data 
> > sharing is not supported in Microsoft Windows 95/98/ME. If 
> the Sun JRE 
> > installer is not being used, this can be done manually, as 
> explained 
> > below. During subsequent JVM invocations, the shared archive is 
> > memory-mapped in, saving the cost of loading those classes and 
> > allowing much of the JVM's metadata for these classes to be shared 
> > among multiple JVM processes." [1]
> >
> > This isn't quite the same as saving JIT'ed code, but it 
> sounds like it 
> > is saving the pre-parsed and verified class files.
> >
> > Nick
> >
> > [1] http://java.sun.com/j2se/1.5.0/docs/guide/vm/class-data-
> > sharing.html
> >

IMPORTANT: This e-mail, including any attachments, may contain private or confidential information.
If you think you may not be the intended recipient, or if you have received this e-mail in
error, please contact the sender immediately and delete all copies of this e-mail. If you
are not the intended recipient, you must not reproduce any part of this e-mail or disclose
its contents to any other party.
This email represents the views of the individual sender, which do not necessarily reflect
those of education.au limited except where the sender expressly states otherwise.
It is your responsibility to scan this email and any files transmitted with it for viruses
or any other defects.
education.au limited will not be liable for any loss, damage or consequence caused directly
or indirectly by this email. 

View raw message