harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From usman bashir <grip...@gmail.com>
Subject Re: Java
Date Wed, 11 May 2005 04:47:59 GMT
Hi!
 i m also in favor of C/C++ because , java will though effective, would cost 
more in performance and time issues that should be considered while doing 
some OOS work and it will also to ensure to reach the boat to some beach as 
well.

 On 5/11/05, Rodrigo Kumpera <kumpera@gmail.com> wrote: 
> 
> Not sure, but how many machine code generation software java have?
> Near-two? JikesRVM and near-to-be-usable SableVM jit? And C/C++? Using
> tools like llvm, iburgs, vmgen and many more can make a huge
> diference.
> 
> Besides that, for a long JikesRVM could not bootstrap from a free JVM,
> last year someone did the trick with Kaffe.
> 
> Rodrigo
> 
> On 5/11/05, 王在祥 <wangzaixiang@gmail.com> wrote:
> > I agree.
> >
> > Also, as a java fans, i would like to write and read Java code, and 
> there
> > will be more contributor to this project if we choice Java as the major
> > implementation language.
> >
> > By using java, we can take advantage of the java such as:
> >
> > 1. IDE support. either Eclipse or NetBeans will makes the project easy 
> to
> > build, and code reading.
> > 2. Refractor support via tools support. which will improve the qualilty.
> >
> > 2005/5/11, Steve Blackburn <Steve.Blackburn@anu.edu.au>:
> > >
> > > I would like advocate the use of Java in implementing the VM (*).
> > > This may seem a low-level issue, but I'm raising it now because it
> > > will have significant implications for the VM core and the overall
> > > approach this project takes.
> > >
> > > Why? a) Software engineering benefits. b) Performance. c) "Eating
> > > your own dog food" is good for you.
> > >
> > > The basic argument goes like this:
> > >
> > > . From the standpoint of development time, providing (and
> > > maintaining) completeness of implementation will be our biggest
> > > challenge. The more we can leverage Java's advantages in
> > > development time and maintainability, the better off we are. The
> > > advantages of strong typing are particularly compelling when
> > > implementing the compiler and GC. This also (largely) addresses
> > > the OS portability concerns being discussed.
> > >
> > > . From the standpoint of VM performance, the user code and libraries
> > > are (largely) written in Java anyway, so they will perform as well
> > > as our JIT allows. As far as the execution of VM code at runtime,
> > > this is dominated by the GC, the JIT, and inlined pseudo-user code
> > > such as barriers and allocation sequences. Experience with MMTk
> > > shows that it is possible to build high performance GCs in Java.
> > > Moreover, because the barriers and allocation sequences are
> > > expressed in Java, the JIT is able to aggressively optimize these.
> > > We found that this advantage and the fact that the size of Java
> > > scalars is statically known meant that we could outperform glibc's
> > > malloc on raw allocation time (size classes are statically
> > > evaluated).
> > >
> > > . "Eating your own dog food" is good for you. It gives you a
> > > compelling reality check. If your compiler isn't good enough for
> > > your own code, what is it good for?
> > >
> > > To those I'll add two more points:
> > >
> > > . A project like this has the opportunity to be aggressive and not be
> > > shackled in the way the existing commercial product VMs are. The
> > > Jikes RVM project at IBM (Java in Java) and Bartok at MSR (C# in
> > > C#) have really shown the potential for this approach.
> > >
> > > . We are a community who believes that Java has something to offer
> > > as a language, and we've demonstrated (GNU Classpath, Jikes RVM,
> > > the entire Jakarta project) that we can produce excellent systems
> > > using Java.
> > >
> > > * Of course it is not possible to implement a high performance GC with
> > > out-of-the box Java 1.4. However the set of extensions required is
> > > modest both in number and in implementation effort. In MMTk we
> > > found it was necessary to add a number of unboxed types to give us
> > > type safety over addresses and object references (while retaining
> > > performance), and we added a number of compiler pragmas for
> > > correctness (interruptability) and performance (inlining). These
> > > extensions have been factored out and are now also used by jnode.
> > >
> > > --Steve
> > >
> > > Research Fellow, Australian National University
> > > phone: +61 2 6125 4821 fax: +61 2 6125 0010
> > > http://cs.anu.edu.au/~Steve.Blackburn
> > >
> > >
> >
> >
> 



-- 
Usman Bashir
Certified IBM XML Solution Developer 
Certified UML Developer
Brainbench Certified Internet Perfessional[advance](BCIP)
Brainbench Certified Java Perfessional (BCJP)
Brainbench Certified .NET Perfessional 
Brainbench Ceritified C++ Perfessional (BCCP)
Software engineer IT24
Faculty Member Operation Badar Lahore
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message