A small documentation contribution

[Nick Lothian <nl...@educationau.edu.au>]

One of the big problems for newcomers to the Harmony project is
discovering what has already been discussed. I suspect this could get
worse as the project expands.

I've started a blog to attempt to summarise the discussions on the
mailing list and elsewhere: http://www.mackmo.com/apacheharmony/default/

The idea is that it will make it easy for people to come up to speed on
issues. For instance, the next time someone suggests not implementing
deprecated APIs they can be pointed at
http://www.mackmo.com/apacheharmony/default/2005/05/11/Deprecated_APIs.h
tml

In the future some of this could get put in a formal FAQ sometime - in
the mean time I'll try and keep it updated. Any suggestions for it are
welcome.

Nick
<nl...@apache.org>


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. 

Re: JIT vs. WAT

[Tom Tromey <tr...@redhat.com>]

>>>>> "Bob" == Bob  <ci...@earthlink.net> writes:

Bob> There's a lot of discussion on JIT vs. WAT.  I think I can lay down
Bob> some framework on the issue.

Bob> WAT-compiled code requires a smaller runtime system, their programs
Bob> load faster, they probably use less memory at runtime, and they run at
Bob> a (more) consistent speed.  This makes WATs especially well-suited for
Bob> PDAs and other mobile devices, which may not have an extra few dozen
Bob> megabytes to spare for a full JIT-based Java system.

And, we think, desktop and small utility use, where the benefits of
reduced startup times and shared libraries are felt more strongly.

Bob> GCJ begins to fall short where you wish to use Java's dynamic
Bob> loading/linking capabilities.  Classes must be loaded dynamically,
Bob> garbage collected when they're no longer used, and integrated with the
Bob> existing code.  They must be bytecode-verified and sandboxed.  I'm
Bob> sure that someone who's really clever could make this all work under
Bob> GCJ.

We've basically done all that in the gcc 4.0 release.  There is a new
ABI that does all its linking at runtime (at some performance cost).
Verification works even for precompiled code.  The origin of classes
is irrelevant; they are looked up in a shared library database; I like
to describe gcj as a "caching jit".

You can even run gcj itself as a jit (in response to an uncompiled
class, compile it to a .so that is then loaded), but this mode still
has some scalability problems.  This does mean that, at the moment,
things like runtime bytecode instrumentation (AOP and friends) don't
mix that well with the gcj approach.

Bob> Finally, as of last summer, GCJ was not "drop-in" compatible with
Bob> Sun's javac.  You cannot just take an Ant script and replace "javac"
Bob> with "gcj" and have it all work.

This is the role that the java-gcj-compat package fills.
jpackage-style alternatives basically solve all the problems in this
area.

Tom

JIT vs. WAT

[Bob <ci...@earthlink.net>]

There's a lot of discussion on JIT vs. WAT.  I think I can lay down 
some framework on the issue.

First of all, we already have examples of both: Sun JDK 1.5 is a highly 
evolved JIT, and GCJ 3 is a highly evolved WAT.  In benchmarks, they 
produce code that runs at comparable speeds.  The speed advantage GCJ 
gains by not having to compile at runtime (and by able to apply 
time-intensive compilation optimizations), it loses by not having 
runtime/profiling information available.  Profiling is a pain, it's 
unlikely most GCJ developers will ever use it.

That said, there are other pros and cons.

WAT-compiled code requires a smaller runtime system, their programs 
load faster, they probably use less memory at runtime, and they run at 
a (more) consistent speed.  This makes WATs especially well-suited for 
PDAs and other mobile devices, which may not have an extra few dozen 
megabytes to spare for a full JIT-based Java system.

WATs also allow tighter integration with non-Java code: GCJ produces 
object code fully compatible with C++.  For this reason, GCJ's CNI 
interface is really fast, while JNI can never be.  If you wish to link 
together a lot of Java and non-Java code as an integrated unit --- for 
example, you wish to do Numerical Analysis using the standard LAPACK 
libraries, or you wish to build a Swing front-end to an existing C/C++ 
program --- CNI will always be more satisfactory.

In general, WATs are very satisfactory for systems programming and 
standard applications programming.

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.

Finally, as of last summer, GCJ was not "drop-in" compatible with Sun's 
javac.  You cannot just take an Ant script and replace "javac" with 
"gcj" and have it all work.  With GCJ, you pretty much want to use the 
GNU build tools.  And if you wish to dynamically load any classes, that 
requires additional tinkering.  These are all issues that, in practice, 
diminish GCJ's full Java compatibility.

In conclusion, I think there's room/place for both approaches.  I'd 
like to see Harmony develop a first-class JIT system, since GCJ has 
already done a good job on the WAT approach.

Re: A small documentation contribution

[Davanum Srinivas <da...@gmail.com>]

Nick,

If you could update the wiki, we'd appreciate it. that way everyone
can contribute to keeping it uptodate. http://wiki.apache.org/harmony/

thanks,
dims

On 5/11/05, Nick Lothian <nl...@educationau.edu.au> wrote:
> 
> One of the big problems for newcomers to the Harmony project is
> discovering what has already been discussed. I suspect this could get
> worse as the project expands.
> 
> I've started a blog to attempt to summarise the discussions on the
> mailing list and elsewhere: http://www.mackmo.com/apacheharmony/default/
> 
> The idea is that it will make it easy for people to come up to speed on
> issues. For instance, the next time someone suggests not implementing
> deprecated APIs they can be pointed at
> http://www.mackmo.com/apacheharmony/default/2005/05/11/Deprecated_APIs.h
> tml
> 
> In the future some of this could get put in a formal FAQ sometime - in
> the mean time I'll try and keep it updated. Any suggestions for it are
> welcome.
> 
> Nick
> <nl...@apache.org>
> 
> 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.
> 


-- 
Davanum Srinivas - http://webservices.apache.org/~dims/

Re: A small documentation contribution

[Ricky Clarkson <ri...@gmail.com>]

Any reason not to use the wiki - http://wiki.apache.org/harmony ?

On 12/05/05, Nick Lothian <nl...@educationau.edu.au> wrote:
> 
> One of the big problems for newcomers to the Harmony project is
> discovering what has already been discussed. I suspect this could get
> worse as the project expands.
> 
> I've started a blog to attempt to summarise the discussions on the
> mailing list and elsewhere: http://www.mackmo.com/apacheharmony/default/
> 
> The idea is that it will make it easy for people to come up to speed on
> issues. For instance, the next time someone suggests not implementing
> deprecated APIs they can be pointed at
> http://www.mackmo.com/apacheharmony/default/2005/05/11/Deprecated_APIs.h
> tml
> 
> In the future some of this could get put in a formal FAQ sometime - in
> the mean time I'll try and keep it updated. Any suggestions for it are
> welcome.
> 
> Nick
> <nl...@apache.org>
> 
> 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.
>