compiling to byte-code vs java

[Per Bothner]

Jonathan Gibbons wrote:
 > 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.

To clarify: I did not implement BlockExpression and generate bytecode
directly from it for performance reasons.  I did so because that seems
both cleaner and simpler than adding an extra compiler phase to re-write
nested expressions into assignments to temporary variables.  This
allowed me to simplify the existing (but incomplete) code to handle
object literals, as another example where a complex expressions needed
a temporary local variable.  (The object literal case can, I believe,
be handled using LetExpr, which is a special case of BlockExpression.)

However, Robest made the point that implementing BlockExpresssion by
direct code generation would generate code that HotSpot would not
be able to optimize as well.  From what John Rose and others have said
on the jvm-languages list, we need not be concerned about this -
generating code to leave the BlockExpression value on the JVM stack
should be at least no worse.

Peter Ahé wrote:
> 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.

There was some surprise on the jvm-languages as this result, and it
was indeed suggested this might be a HotSpot bug.
-- 
	--Per Bothner
per.bothner at sun.com   per at bothner.com   http://per.bothner.com/