harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/
Date Thu, 19 May 2005 13:29:44 GMT
Renaud BECHADE wrote:
>>>That being said...doing so in a portable and platform independent way is 
>>>actually HARDER in Java than in C (and by C I mean 
>>>C/C++/Objective-C...whatever).  Read the Sable paper...  you'll see what 
>>>I mean :-)
> Why should it be so? I guess the platform dependent code emission code is
> err ... not platform independent anyway. Also, if the reference platform is
> for instance LLVM, or some other, off the shelf, low-level intermediate
> representation, then there is no more platform dependence to take care of at
> the JVM level (I suppose)...

Andy is right: "writing in Java" *above* the JVM interface means you are
creating bytecode and all the portability efforts were taken care for
you by the JVM makers. "writing in Java" *below* the JVM interface means
that you have to do, at some point, some native code transformations
yourselfs, for every single different CPU architecture.

Writing a JVM in a compilable higher language means that the compiler
will do all that for you.

So, interestingly enough, writing a JVM in java could allow java
developers to work on it more easily (java programmers tend to be
allergic to C and friends), but would require a lot more work,
portability wise.

It's also true that this kind of portability is perfectly parallelizable
and it's CPU-dependent, not OS-dependent (well, really it's
(CPU,OS)-dependent, but the two are almost orthogonal axis) and there
are not so many CPU architectures remaining out there in the server market.

This might hit us on the mobile/embedded market, though and hit us
pretty hard.

This is why I would like Harmony to have two VMs, one written in java
and one written in C-or-friends: this would give us

 1) the goal of making things modular enough to allow to swap things
around and allow parallel development

 2) create some internal (and friendly!) competition on speed and
compliance :-)

 3) attract two different pools of talents

 4) allow compensation (easier to experiment in java than in C, harder
to port java than C)



View raw message