On May 19, 2005, at 9:29 AM, Stefano Mazzocchi wrote:
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.
I think that's a function of whether or not you ever worked in C and C ++. I spent a lot of time with C and C++ and have no problem using it when required, although it hasn't been required in what I do for a long time.
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)
Thoughts?
I'm certainly open to having two, but don't think that it should be in any way a goal. If there's interest, and people work on it, I think that's great - it's good for portability testing. I'd ask that we require working together on the modularity.
I know that in the past, that Jikes was able to clean some production VMs in microbenchmarks, but as I understand it, there's now a large performance gap. One of our goals is equivalent performance.
geir
-- Stefano.
-- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
