ObjectWeb Consortium
Search ObjectWeb Mail Archive: 

Advanced Search - Powered by Google


Mail Archive Home | architecture List | September 2003 Index

<--  Date Index  --> <--  Thread Index  -->

Re-6: [ObjectWeb architecture] just an idea for (Java) native compilation


Very interesting comparison. I agree to most of the content, even I think 
that you missed two things:
1) There already are embedded Java solutions that run as fast as native C 
code on cell phones and iPAQ. See www.savaje.com for example. Even SavaJE OS 
2.0 only contains J2ME, SavaJE OS 1.0 contained J2SE and was approved running 
same speed than native C code on an iPAQ.
2) Stripping down Java and needed packages is no solution, since this is an 
unfair comparison. If you strip down Java for your own needs, don't compare 
it to Sun J2SE, but compare it to SavaJE OS 2.0 (J2ME), since that would be a 
fair comparison then.
3) You cannot just strip down everything since for example JOnAS has to 
provide J2EE compatibility. J2EE for example clearly tells that complete J2SE 
has to be provided on the server. You cannot do this by stripping down. Sure, 
with other ObjectWeb projects you can, but I see JOnAS as the main project 
currently.
4) The memory footprint of J2SE, especially of the Sun VMs, will be reduced 
significantly by the Tiger 1.5 release which is currently under development. 
If you compare future ideas, you need to compare with future Java 1.5 also. 
You cannot compare a more than one year old Sun VM with an experimental one 
that you cannot release before the next half year is over, so compare it with 
Java 1.5.
5) Hardware is getting more powerful every day, even in embedded systems. 
There actually are very good-selling micro PCs on the market (e. g. from 
www.jumptec.de) that come here with 128MB of RAM plus 128MB Flash, for a low 
price (scaled about 7 per 5 cm, see 
http://www.jumptec.de/product/data/xboard/xb1_ds.pdf). Even the digital 
camera I bought last week (Canon EOS 300D) accepts a CF card with 4 GB (!) of 
RAM and uses on board photo editing software! Current micro controllers are a 
lot more powerful than we all think. So the questions is: Is there a need to 
develop a stripped subset of a VM that runs on a machine that is smaller than 
what you actually can buy in the store? What actually is the target hardware 
to run on and who needs ObjectWeb software to run on it?

Have Fun
Markus

-------- Original Message --------
Subject: Re: Re-4: [ObjectWeb architecture] just an idea for (Java) native 
compilation (26-Sep-2003 14:53)
From:    jeanphilippe.fassino@xxxxxxxxxxxxxxxxxxxx
To:      markus.karg@xxxxxxxxx

> Hi, look at my presentation of this morning to the Objectweb
> architecture meeting which
> present some micro benchmarks between GCJ 3.3.1 and Sun JVM 1.4.1 (JIT
> & Interpreted).
> (This benchmark which was run in the conditions you mention let
> thinking that HotSpot
> is better in performance and don't consume more memory).
>
> Best regards,
>
> JP
>
>
> Le vendredi, 26 sep 2003, à 09:57 Europe/Paris, <markus.karg@xxxxxxxxx>
> a écrit :
>
> > Thank you for the links. Actually what that guy did was micro
> > benchmarking. This is unfair for java and other late-compiling VMs:
> > What that guy measures includes the startuptime of the VM, also
> > measures interpreted (!) code (not hot spot compiled code). To measure
> > hot spot compiled code, you need to put all functions into one,
> > execute that function one million times, then look the average value.
> > That's a real life test. No one cares on the java.exe startup time in
> > a server environment! No one cares the first 100 iterations of an
> > algorithm being run in iterpreted mode if the next 24 hours this
> > server will execute the same function one million time in hot spot
> > compiled mode.
> >
> > To write fair measuring micro benchmarks you need to know how hot spot
> > VMs work. That guy seems not to know (I told him today). So I'm
> > looking forward to see the actual results done with fair tests.
> >
> --
> Jean-Philippe Fassino
> France Télécom R&D/DTL/ASR
> Ingénieur Recherche & Développement
> 28, chemin du vieux chêne
> 38243 Meylan Cedex
> Tel : + 33 (0) 4 76 76 45 52
> Fax : + 33 (0) 4 76 76 45 57
> http;//www.francetelecom.com/rd
>
>
>
> To: markus.karg@xxxxxxxxx
> Cc: jeanphilippe.fassino@xxxxxxxxxxxxxxxxxxxx
>     architecture@xxxxxxxxxxxxx




<--  Date Index  --> <--  Thread Index  -->

Reply via email to:

Powered by MHonArc.

Copyright © 1999-2005, ObjectWeb Consortium | contact | webmaster.