harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From acoli...@apache.org
Subject Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/ (and some bla bla about compilers and stuff)
Date Fri, 20 May 2005 05:59:23 GMT
> 
> 
> The JCVM docs talks about possible support for generating ELF binaries
> usign just Java code, although this doesn't appear complete at this
> point. See
> http://jcvm.sourceforge.net/share/jc/doc/jc.html#Java%20to%20ELF
> 
> 
> GCC also has its own internal format (called RTL I think). I don't know
> much (anything) about that, but it is easy to speculate about producing
> RTL from bytecode and feeding it to the compiler. I'd speculate that GCJ
> works something like this.
> 

RTL is Register Transfer Language I believe.  RTL is kinda like an 
abstract assembler language, however its not exactly multiplatform. 
Meaning the RTL generated for each platform may differ.

Writing a GCC front end is actually rather non-trivial I'm afraid. 
While it does do a traditional AST tree more or less, its implemented 
with some rather complicated and undocumented macros (and from what I 
remember a few layers of them).

Its unlikely that GCC is going to change license or offer an exemption 
so more or less taking code from GCC itself is not legally feasible for 
an ASL project.  On the other hand, I'm not convinced that GCC is an 
acceptable compiler for a JIT anyhow.  Allow me to demonstrate.  Find a 
large C project (say 1000 sources).  Build the project on a fairly fast 
machine.

Okay, now boot up your favorite Java Application Server (whichever that 
may be).  Imagine if it took that long to start up.  Sure it would be 
fast once it did.  However, due to how default Java classloading works 
(by lazy loading when it is asked for) there would be a perceived 
performance impact.  We COULD mark some classes hot and the such, but it 
would still be jerky and appear slow. Its possible that you could rip 
pieces of GCC out and construct a more traditional JIT, but its really 
not what we want.

So there are probably people here who know more about it than me.  I'm 
just a simple southern boy who reads compiler books in the bathroom.  As 
I understand it though, a runtime compiler requires a slightly blacker 
belt of compiler writing.  You need to not only try and generate 
efficient native code, but optimize compiler time so that no one notices 
that you did it!  One approach to this is to generate code that has been 
through the first few levels of optimization and then do the native 
optimizations on another pass.  (Generally starting up in interpreted 
mode)  This is actually kinda smart, because many of the highest yield 
optimizations are these early optimizations (variable elimination, local 
and global common subexpression elimination, algebraic simplification, 
copy propagation, constant propagation, loop-invariant optimization, 
etc).  While the native and headier stuff should be done, since the Java 
compiler can optimize and performs some optimizations, its unlikely to 
be the highest yield most of the time.  This does mean that more work 
will have to be done and redone to get to the most optimal code, but the 
pause should be low.

Some of the things we COULD do to get things up and running are very 
cool for that purpose, but ultimately we'll probably have to do the 
heavy lifting of writing a JIT that balances the force while trying to 
slay the complexity dragon....

-Andy

> 
>>Keep in mind I know squad about GCC and friends.
> 
> 
> Me neither.
> 
> Nick
> 
> 
> 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. 
> .
> 


-- 
Andrew C. Oliver
SuperLink Software, Inc.

Java to Excel using POI
http://www.superlinksoftware.com/services/poi
Commercial support including features added/implemented, bugs fixed.

Mime
View raw message