harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Renaud BECHADE" <renaud.bech...@numerix.com>
Subject RE: timeframe for mid-level decissions
Date Thu, 19 May 2005 02:22:57 GMT

http://jnode.sourceforge.net/portal/node/623
By the way and since it seems JNode already supports Java5.0 features
(except "annotations") this might just be an "immediate" solution....

RB

"Il n'y a que les imbeciles qui ne changent pas d'avis, c'est mon avis
depuis toujours"

-----Original Message-----
From: Renaud BECHADE [mailto:renaud.bechade@numerix.com]
Sent: Thursday, May 19, 2005 10:28 AM
To: 'harmony-dev@incubator.apache.org'
Subject: RE: timeframe for mid-level decissions



>* Stay close to the operating system - GCJ,LLVM,... - See
> http://www.research.ibm.com/vee04/Boehm.pdf

Especially as GCJ and LLVM (especially LLVM) are relatively fast, NOW.
(I remember comparing some floating point test between gcc -O 10^8 and
llvm-gcc + llvi. The llvm was damn fast on my machine - I think I had a 20%
or 30% improvement, which is indeed quite good - so good as say the Intel
compiler or so on Intel machines. That was a pity Objective-C was not
available :-( )

>I am currently working with LLVM as part of my diploma thesis and really
>like it for its open possibilties (for other languages too) and for its
>typed ssa risk-like ir specification. The compiler implementation is
>also quite nice and it would give enough room to implement many features
>and different runtimes [http://www.research.ibm.com/vee04/Grove.pdf] .
>
>As a side node:
>Also the LLVM guys are heavily thinking about implementing many
>intrinsics based on APR and other core libraries. Sure there are many
>things which have to be built yet (garbage collecter, memory model
>(which is very low level right now) ...) but a llvm-java frontend is
>arleady being worked on.

Since GCJ and GCC share the same code generator, and since GCC code
generator has been ported to LLVM (with may-be heavy changes, though), why
not just make sure a GCJ-LLVM-with-jit-plugin is developed, once GCJ gets
some minimal support for java5 bytecode ("all-except-reflection")?
So far as I know, LLVM enables or is scheduled to enable at-runtime LLVM
bytecode generation (used for Ruby and Scheme interpreters I think[1]), so
that we could have a cool JIT without the burden of actually generating
low-level machine code (kind of a write once, run everywhere JIT).
This kind of plan could also have the theoretical advantage of being able to
release early and on a very big bunch of architectures code that /actually/
works, and is kind-of used by default by many, many, many people (*BSD
users, embedded systems, linux hackers, and so on).

Regards,

RB (fed up with Sun JDK weird open-source licensing that forces freebsd
users to download everything by hand...)

[1] sorry for any technical mistake.

-----Original Message-----
From: news [mailto:news@sea.gmane.org] On Behalf Of Jakob Praher
Sent: Thursday, May 19, 2005 5:30 AM
To: harmony-dev@incubator.apache.org
Subject: timeframe for mid-level decissions

hi people,

first of all it's great to hear so much harmony for open source java!

Ever since I'm working with open source java software, I was dreaming of
a great open source java vm movement. Now given the amount of great
people involved here sounds it would truly be possible.

Now the reason why I write this mail, is that I'd like to see some
actual timelines put up and I would like to see a separation of the
philosophical (long-term) issues from implementation issues (tasks that
can be started assap).

The central point is:

When do you want the first Harmony J2SE alpha snapshots to reach the masses?

>From this central question, I think the tasks which are of highest priority:
-> Which VM(s) should be chosen? [this will be the hardest decision]
-> Should there be a compatibilty Layer between VMs (like the Classpath
VM classes)

IMHO it would be important to take a multi-layer approach:

A) A short term project (ship it early and improve it along the way)
B) A mid term project (use the huge amount of knowledge which is out
there in the vm projects and build on that)

Some "advices":

* First try to be conservative and build a VM based on what works now,
and try to gain people by actually having a VM that works quite good.
[ I don't think that building a VM in java is good for achieving that
results for now ]

* Stay close to the operating system - GCJ,LLVM,... - See
http://www.research.ibm.com/vee04/Boehm.pdf

I am currently working with LLVM as part of my diploma thesis and really
like it for its open possibilties (for other languages too) and for its
typed ssa risk-like ir specification. The compiler implementation is
also quite nice and it would give enough room to implement many features
and different runtimes [http://www.research.ibm.com/vee04/Grove.pdf] .

As a side node:
Also the LLVM guys are heavily thinking about implementing many
intrinsics based on APR and other core libraries. Sure there are many
things which have to be built yet (garbage collecter, memory model
(which is very low level right now) ...) but a llvm-java frontend is
arleady being worked on.

But to be clear - the message from my side: fix decision deadlines and
stick to them. build something, ship it early. This is the only way to make
*) testers/developers aware
*) gain ground in the VM cake

just some thoughts form my side.
-- Jakob


Mime
View raw message