compiling to byte-code vs java

[Peter Ahé]

If you can demonstrate a 20% performance improvement, it could make
sense for javac to be able to use the stack for intermediate results
(either by adding this as an optimization or supporting special tree
nodes that does not match Java source code).  However, this could be a
HotSpot issue instead.

Cheers,
Peter

On 8/10/07, Jonathan Gibbons <Jonathan.Gibbons at sun.com> wrote:
> Per,
>
> I don't doubt that you might be able to do better by going straight to
> bytecodes.
> The issue was always that it was thought to be quicker and safer to create
> a
> compiler that went via Java trees.   The optimizations could come in phase
> 2,
> once we have a working compiler.  Until then, it is more important to create
> a compiler that works that to polish the bits.
>
> -- Jon
>
>
>
>
>
> On Aug 10, 2007, at 5:48 AM, Per Bothner wrote:
>
> This appears to be relevant to the issue of whether to compile
> "Java trees" or make use of javafx-specific code generation.
> The code is about generating Java vs bytecodes, but it also
> applies to whether we should re-write to Java ASTs or generate
> code directly from ExpressionBlock.
>
> I'll ask for more information, but the message seems to
> suggest that pushing values of the JVM stack is more efficient
> than using temporary variables (as you would have to when
> generating Java ASTs or Java source).
> --
>  --Per Bothner
> per.bothner at sun.com   per at bothner.com   http://per.bothner.com/
>
> From: David Pollak <feeder.of.the.bears at gmail.com>
> Date: August 9, 2007 8:08:04 AM PDT
> To: jvm-languages at googlegroups.com
> Subject: Re: Language Role Call, and a Call to Action
> Reply-To: jvm-languages at googlegroups.com
>
>
>
>
> On 8/9/07, Charles Oliver Nutter <charles.nutter at sun.com> wrote:
> >
> > parren wrote:
> > > On Aug 5, 10:59 pm, Charles Oliver Nutter <charles.nut... at sun.com>
> > > wrote:
> > >> Please reply to this email with just a couple words describing what
> > >> group you represent (language implementation, library implementation,
> > >> JVM implementation, employer, whatever) so we can get some sort of
> tally
> > >> of who's on the line.
> > >
> > > I represent the Abacus Formula Compiler - a spreadsheet to JVM
> > > bytecode compiler used to let users customize computations inside of,
> > > for example, financial applications. Still closed source, but soon to
> > > be GPLed, at least. Uses a mini functional language internally that
> > > gets compiled (fold et al.). But: it currently aims at being fully
> > > decompilable by JODE to Java source so people can understand what it
> > > generated. Might preclude using new features the JVM is going to
> > > introduce.
> >
> > Interesting. You say you compile straight to bytecode though? What about
> > just generating Java code as an intermediate step? I believe this is how
> > Quercus works, and I know of a few others that do this rather than
> > bytecode generation.
>
> When I did the byte-code generator for the Integer spreadsheet, I found
> there were efficiencies gained by keeping intermediate results on the stack
> which one does not get with spreadsheet -> Java -> byte-code.  In some
> cases, I got 20%+ performance improvement.
>
> > - Charlie
> >
> >
> >
> >
>
>
>
> --
> lift, the fast, powerful, easy web framework
> http://liftweb.net
>  --~--~---------~--~----~------------~-------~--~----~
>  You received this message because you are subscribed to the Google Groups
> "JVM Languages" group.
>  To post to this group, send email to jvm-languages at googlegroups.com
>  To unsubscribe from this group, send email to
> jvm-languages-unsubscribe at googlegroups.com
>  For more options, visit this group at
> http://groups.google.com/group/jvm-languages?hl=en
>  -~----------~----~----~----~------~----~------~--~---
>
>
>