You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by ac...@apache.org on 2005/05/20 07:59:23 UTC
Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/
(and some bla bla about compilers and stuff)
>
>
> The JCVM docs talks about possible support for generating ELF binaries
> usign just Java code, although this doesn't appear complete at this
> point. See
> http://jcvm.sourceforge.net/share/jc/doc/jc.html#Java%20to%20ELF
>
>
> GCC also has its own internal format (called RTL I think). I don't know
> much (anything) about that, but it is easy to speculate about producing
> RTL from bytecode and feeding it to the compiler. I'd speculate that GCJ
> works something like this.
>
RTL is Register Transfer Language I believe. RTL is kinda like an
abstract assembler language, however its not exactly multiplatform.
Meaning the RTL generated for each platform may differ.
Writing a GCC front end is actually rather non-trivial I'm afraid.
While it does do a traditional AST tree more or less, its implemented
with some rather complicated and undocumented macros (and from what I
remember a few layers of them).
Its unlikely that GCC is going to change license or offer an exemption
so more or less taking code from GCC itself is not legally feasible for
an ASL project. On the other hand, I'm not convinced that GCC is an
acceptable compiler for a JIT anyhow. Allow me to demonstrate. Find a
large C project (say 1000 sources). Build the project on a fairly fast
machine.
Okay, now boot up your favorite Java Application Server (whichever that
may be). Imagine if it took that long to start up. Sure it would be
fast once it did. However, due to how default Java classloading works
(by lazy loading when it is asked for) there would be a perceived
performance impact. We COULD mark some classes hot and the such, but it
would still be jerky and appear slow. Its possible that you could rip
pieces of GCC out and construct a more traditional JIT, but its really
not what we want.
So there are probably people here who know more about it than me. I'm
just a simple southern boy who reads compiler books in the bathroom. As
I understand it though, a runtime compiler requires a slightly blacker
belt of compiler writing. You need to not only try and generate
efficient native code, but optimize compiler time so that no one notices
that you did it! One approach to this is to generate code that has been
through the first few levels of optimization and then do the native
optimizations on another pass. (Generally starting up in interpreted
mode) This is actually kinda smart, because many of the highest yield
optimizations are these early optimizations (variable elimination, local
and global common subexpression elimination, algebraic simplification,
copy propagation, constant propagation, loop-invariant optimization,
etc). While the native and headier stuff should be done, since the Java
compiler can optimize and performs some optimizations, its unlikely to
be the highest yield most of the time. This does mean that more work
will have to be done and redone to get to the most optimal code, but the
pause should be low.
Some of the things we COULD do to get things up and running are very
cool for that purpose, but ultimately we'll probably have to do the
heavy lifting of writing a JIT that balances the force while trying to
slay the complexity dragon....
-Andy
>
>>Keep in mind I know squad about GCC and friends.
>
>
> Me neither.
>
> Nick
>
>
> IMPORTANT: This e-mail, including any attachments, may contain private or confidential information. If you think you may not be the intended recipient, or if you have received this e-mail in error, please contact the sender immediately and delete all copies of this e-mail. If you are not the intended recipient, you must not reproduce any part of this e-mail or disclose its contents to any other party.
> This email represents the views of the individual sender, which do not necessarily reflect those of education.au limited except where the sender expressly states otherwise.
> It is your responsibility to scan this email and any files transmitted with it for viruses or any other defects.
> education.au limited will not be liable for any loss, damage or consequence caused directly or indirectly by this email.
> .
>
--
Andrew C. Oliver
SuperLink Software, Inc.
Java to Excel using POI
http://www.superlinksoftware.com/services/poi
Commercial support including features added/implemented, bugs fixed.
Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/ (and some bla bla about compilers and stuff)
Posted by usman bashir <gr...@gmail.com>.
awwww! we dont need any mess right up now so leave it now ;)
On 5/22/05, Ben Laurie <be...@algroup.co.uk> wrote:
>
> Stefano Mazzocchi wrote:
> > People, as you probably already understand, being focused on web stuff,
> > Apache attracted pools of people (ourselves mentors included) that know
> > very very little about compilers and VMs.
>
> Speak for yourself - I've written compilers and VMs, though not for Java
> and quite a long time ago now. It's very educational, you should try it
> someday.
>
> Cheers,
>
> Ben.
>
> --
> http://www.apache-ssl.org/ben.html http://www.thebunker.net/
>
> "There is no limit to what a man can do or how far he can go if he
> doesn't mind who gets the credit." - Robert Woodruff
>
--
Usman Bashir
Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/
(and some bla bla about compilers and stuff)
Posted by Ben Laurie <be...@algroup.co.uk>.
Stefano Mazzocchi wrote:
> People, as you probably already understand, being focused on web stuff,
> Apache attracted pools of people (ourselves mentors included) that know
> very very little about compilers and VMs.
Speak for yourself - I've written compilers and VMs, though not for Java
and quite a long time ago now. It's very educational, you should try it
someday.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/ (and some bla bla about compilers and stuff)
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On May 21, 2005, at 4:14 PM, Stefano Mazzocchi wrote:
> Geir Magnusson Jr. wrote:
>
>>
>> On May 21, 2005, at 9:51 AM, Stefano Mazzocchi wrote:
>>
>>
>>>
>>> If the mentors of this project were to write a JVM themselves,
>>> it would
>>> be a piece of crap :-)
>>>
>>
>> Don't sell everyone so short... :)
>>
>
> Prove me wrong! :-)
I have no doubts :)
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/
(and some bla bla about compilers and stuff)
Posted by Stefano Mazzocchi <st...@apache.org>.
Geir Magnusson Jr. wrote:
>
> On May 21, 2005, at 9:51 AM, Stefano Mazzocchi wrote:
>
>>
>> If the mentors of this project were to write a JVM themselves, it would
>> be a piece of crap :-)
>
> Don't sell everyone so short... :)
Prove me wrong! :-)
--
Stefano.
Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/ (and some bla bla about compilers and stuff)
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On May 21, 2005, at 9:51 AM, Stefano Mazzocchi wrote:
>
> If the mentors of this project were to write a JVM themselves, it
> would
> be a piece of crap :-)
Don't sell everyone so short... :)
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/
(and some bla bla about compilers and stuff)
Posted by Stefano Mazzocchi <st...@apache.org>.
Tom Tromey wrote:
>> Does anybody know if GCC allows such a thing?
>It already exists -- you're describing gcj.
on another email, he wrote:
> You can use gcj-as-jit right now, today, if you want, though it has
> some scalability problems.
ohhhh, ok [I should really do my homework]
People, as you probably already understand, being focused on web stuff,
Apache attracted pools of people (ourselves mentors included) that know
very very little about compilers and VMs.
As you might or might not know, this should not scare you: our intent
for harmony was done, exactly, to attract that pool of talents, from the
free java world, the academic world and the not-really-GPL-loving
industrial world.
If the mentors of this project were to write a JVM themselves, it would
be a piece of crap :-) So, consider our comments a way to stir the pot,
rather than a way to provide technical direction: with their mentor hats
on, nobody here will ever provide/dictate/mandate a technical decision,
that is left to the community. We will just try to lubricate the social
process (hopefully mostly in the background, to avoid getting in the
way) so that the technical one can advance more smoothly.
So, in short, I apologize in advance for our eventual cluelessness or
ignorance on the existing free/open java implementation or approaches.
--
Stefano.
Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/ (and some bla bla about compilers and stuff)
Posted by Tom Tromey <tr...@redhat.com>.
>>>>> "acoliver" == acoliver <ac...@apache.org> writes:
acoliver> RTL is Register Transfer Language I believe.
Yes. But front ends don't generate RTL.
acoliver> Writing a GCC front end is actually rather non-trivial I'm
acoliver> afraid. While it does do a traditional AST tree more or less, its
acoliver> implemented with some rather complicated and undocumented macros (and
acoliver> from what I remember a few layers of them).
This is how it worked a few years ago. Nowadays, with the new
infrastructure in GCC 4.0, writing a front end is like an order of
magnitude simpler. It still isn't easy, but there is a lot more
documentation and the overall picture makes a lot more sense.
acoliver> On the other hand, I'm not convinced that GCC is
acoliver> an acceptable compiler for a JIT anyhow. Allow me to demonstrate.
acoliver> Find a large C project (say 1000 sources). Build the project on a
acoliver> fairly fast machine.
Have you tried gcj?
At startup you don't compile everything. You compile it beforehand.
Startup time of the generated programs is one of gcj's strengths.
You can use gcj-as-jit right now, today, if you want, though it has
some scalability problems. It isn't as slow as you might think if
you're used to the C compiler; compiling the typical .class file in
isolation is a fairly cheap operation.
acoliver> Its possible
acoliver> that you could rip pieces of GCC out and construct a more traditional
acoliver> JIT, but its really not what we want.
Probably more profitable to simply integrate a JIT into libgcj.
Tom
Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/ (and some bla bla about compilers and stuff)
Posted by Rodrigo Kumpera <ku...@gmail.com>.
jikesRVM have 3 compilers, baseline, quick and opt.
baseline is meant to have jit times comparable to an interpreter preparation
time[1].
quick is a replacement for baseline on PPC, as the generated code is too
slow, and aim to only get low hanging fruits. It's a linear, one pass
compiles, so it doesn't perform any of the fancy (and time demanding)
optimizations you suggest.
opt is the optimizing compiler that goes as further as possible on
performance.
HotSpot have interpreter, client and server compiler. The big diference is
that in server mode code is recompiled once one of it's dependencies is
resolved (think of incremental whole program global optimization) and
speculative optimizations are done (like inlining/devirtualizing
should-be-virtual methods) [2].
A good JVM needs not only great JITers and GCs, but work in a adaptative
way, doing only the most profitable things for the user. Eg, if compiling
with opt will take more time the total method execution time in interpreted
mode, then don't.
Rodrigo
[1] SableVM shows that with some preparation interpreting can be a lot
faster, see Etiene phd thesis for a great explanation about this.
[2]OVM, I think, does some of this by class hierachy analisis for example.
On 5/20/05, acoliver@apache.org <ac...@apache.org> wrote:
>
> >
> >
> > The JCVM docs talks about possible support for generating ELF binaries
> > usign just Java code, although this doesn't appear complete at this
> > point. See
> > http://jcvm.sourceforge.net/share/jc/doc/jc.html#Java%20to%20ELF
> >
> >
> > GCC also has its own internal format (called RTL I think). I don't know
> > much (anything) about that, but it is easy to speculate about producing
> > RTL from bytecode and feeding it to the compiler. I'd speculate that GCJ
> > works something like this.
> >
>
> RTL is Register Transfer Language I believe. RTL is kinda like an
> abstract assembler language, however its not exactly multiplatform.
> Meaning the RTL generated for each platform may differ.
>
> Writing a GCC front end is actually rather non-trivial I'm afraid.
> While it does do a traditional AST tree more or less, its implemented
> with some rather complicated and undocumented macros (and from what I
> remember a few layers of them).
>
> Its unlikely that GCC is going to change license or offer an exemption
> so more or less taking code from GCC itself is not legally feasible for
> an ASL project. On the other hand, I'm not convinced that GCC is an
> acceptable compiler for a JIT anyhow. Allow me to demonstrate. Find a
> large C project (say 1000 sources). Build the project on a fairly fast
> machine.
>
> Okay, now boot up your favorite Java Application Server (whichever that
> may be). Imagine if it took that long to start up. Sure it would be
> fast once it did. However, due to how default Java classloading works
> (by lazy loading when it is asked for) there would be a perceived
> performance impact. We COULD mark some classes hot and the such, but it
> would still be jerky and appear slow. Its possible that you could rip
> pieces of GCC out and construct a more traditional JIT, but its really
> not what we want.
>
> So there are probably people here who know more about it than me. I'm
> just a simple southern boy who reads compiler books in the bathroom. As
> I understand it though, a runtime compiler requires a slightly blacker
> belt of compiler writing. You need to not only try and generate
> efficient native code, but optimize compiler time so that no one notices
> that you did it! One approach to this is to generate code that has been
> through the first few levels of optimization and then do the native
> optimizations on another pass. (Generally starting up in interpreted
> mode) This is actually kinda smart, because many of the highest yield
> optimizations are these early optimizations (variable elimination, local
> and global common subexpression elimination, algebraic simplification,
> copy propagation, constant propagation, loop-invariant optimization,
> etc). While the native and headier stuff should be done, since the Java
> compiler can optimize and performs some optimizations, its unlikely to
> be the highest yield most of the time. This does mean that more work
> will have to be done and redone to get to the most optimal code, but the
> pause should be low.
>
> Some of the things we COULD do to get things up and running are very
> cool for that purpose, but ultimately we'll probably have to do the
> heavy lifting of writing a JIT that balances the force while trying to
> slay the complexity dragon....
>
> -Andy
>
> >
> >>Keep in mind I know squad about GCC and friends.
> >
> >
> > Me neither.
> >
> > Nick
> >
> >
> > IMPORTANT: This e-mail, including any attachments, may contain private
> or confidential information. If you think you may not be the intended
> recipient, or if you have received this e-mail in error, please contact the
> sender immediately and delete all copies of this e-mail. If you are not the
> intended recipient, you must not reproduce any part of this e-mail or
> disclose its contents to any other party.
> > This email represents the views of the individual sender, which do not
> necessarily reflect those of education.au limited except where the sender
> expressly states otherwise.
> > It is your responsibility to scan this email and any files transmitted
> with it for viruses or any other defects.
> > education.au limited will not be liable for any loss, damage or
> consequence caused directly or indirectly by this email.
> > .
> >
>
>
> --
> Andrew C. Oliver
> SuperLink Software, Inc.
>
> Java to Excel using POI
> http://www.superlinksoftware.com/services/poi
> Commercial support including features added/implemented, bugs fixed.
>