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: Other interesting papers and research
Date Mon, 23 May 2005 08:48:23 GMT

>Summing up, I support the idea of a java/bytecode to C compiler that can
>be bundled with gcc. As stated we would gain portability and we can use
>all facilities provided by gcc.

To me it sounds a bit like gcj... In order to use a low level bytecode as an
intermediate representation, LLVM bytecode (which can be emitted by a
modified version of gcc [may be useful for rapid prototyping]) could be a
realization of your ideas, IMHO. Another way I see it would be to use a
simplified version of Java bytecode to represent low-level instructions (as
the Squeak Smalltalk VM works: only static methods and a restricted class
set is supported, this way it is possible to run the VM in itself, and also
to machine-generate C code from the VM sources. In modern days we might
consider generating LLVM bytecode - or simply use gcj! For this kind of
architecture, for instance [1])



[1] not sure about the implications in terms of speed, though. In my point
of view it is better, anyway, to have a working system first and then hook
bestial optimizations latter [once the execution model is simple enough or
rather close enough to a reasonable machine abstraction this might be
somewhat easier/less difficult]

PS: I am favorable to use a "java in java" VM as a plugin to such a system.
(or rather, have a "stock" VM with fast uptimes as bootstrap and then a
"very optimizing" plugin, which does not need to tackle with anything but
code generation itself - if this is really possible)

-----Original Message-----
From: Ariel Sabiguero Yawelak [mailto:asabigue@fing.edu.uy]
Sent: Monday, May 23, 2005 5:06 PM
To: harmony-dev@incubator.apache.org
Subject: Re: Other interesting papers and research

Other interesting things that can be achieved are some sorts of high
performance "tunning" aspects, which are very interesting, and using gcc
power might be more interesting than redoing it from scratch, either, at
the begining of current project, or maybe forever.
An adequate "bundle" of gcc and harmony might produce a JIT/WAT
java/bytecode compilation. Moreover, the compilation parameters might be
"tuneable" by the JVM administrator and choose between compilation
speed, compilation performance, memory footprint, etc.
Appart from code-reusing, there is also an adequate sort of abstraction
that is good here. and concentrating on this, we avoid discussing
machine level details as we all agree that GCC is portable, performant
and adequate.
Summing up, I support the idea of a java/bytecode to C compiler that can
be bundled with gcc. As stated we would gain portability and we can use
all facilities provided by gcc.


Archie Cobbs wrote:

> acoliver@apache.org wrote:
>> The approach of using C Compiler generated code rather than writing a
>> full compiler appeals to me:
>> http://www.csc.uvic.ca/~csc586a/papers/ertlgregg04.pdf
>> I am curious on how well the approach performs compared to existing
>> JITs.
> I'm admittedly biased, but the approach of using the C compiler has
> some good benefits, mainly in portability. This is especially true for
> architectures like x86 that have a complicated instruction set, where
> optmization is a subtle art. Though JC uses the C compiler as a WAT
> instead of a JIT, it is very portable (to any architecture that GCC
> targets) as a result. To the extent that portability is a goal, this
> might make sense as an approach to take, at least initially.
> -Archie
> __________________________________________________________________________

> Archie Cobbs      *        CTO, Awarix        *
> http://www.awarix.com

View raw message