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: JIT vs. WAT
Date Thu, 12 May 2005 23:36:00 GMT
[snip]
> 
> GCJ begins to fall short where you wish to use Java's dynamic 
> loading/linking capabilities.  Classes must be loaded 
> dynamically, garbage collected when they're no longer used, 
> and integrated with the existing code.  They must be 
> bytecode-verified and sandboxed.  I'm sure that someone who's 
> really clever could make this all work under GCJ.  
> But it essentially requires the "glueing together" of two 
> very distinct compilation models --- the static and the 
> dynamic.  And it is unsatisfactory for many applications if 
> the dynamically loaded code behaves differently --- for 
> example, runs 3-5X slower because it's being interpreted.  A 
> fully dynamic fully JIT-based system seems simpler and more 
> likely to work well for these applications.
> 

This is a really big deal.

Most modern Java programs make extensive use of dynamic loading &
linking, and that usage is increasing.

Recent releases of the Sun VM have put a lot of emphasis on speeding up
the performance of reflection and this has been one of the big
performance boosters in these VMs.

[snip]

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. 

Mime
View raw message