[Gllug] One more time...

[Nix]

[very late, catching up]

On Wed, 11 Jun 2003, Pete Ryland muttered drunkenly:
> On Wed, Jun 11, 2003 at 01:30:05AM +0100, Nix wrote:
>> ... of course, Sun's javac coesn't have significant interunit
>> optimization. But this is good preparation for the days when it will
>> have.
> 
> And with late binding you can supposedly re-compile running code.  I'm still
> waiting.. :-)

Um, it's been done, at least twice. (That i386 emulator on the Alpha,
and valgrind. Of the two, the only one whose source is available is
valgrind; its internals are truly fascinating.)

>> languages), the JVM (a rather nice, if rather Java-specific, virtual
>> machine)
> 
> Hmm.. I have to question that the JVM is nice.  I would have thought that a
> 3AC machine would have been much better than a 0-address one.

Yeah, in general I dislike stack machines, but a Sufficently Good
Optimizer can semi-trivially transform stack-machine based code into
efficient code for register machines. (Of course, doing that *optimally*
is NP-complete, but we don't need optimality, and the nice thing about
transforming running code is that you can keep searching for better
solutions in idle time :) of course, nobody does this yet.)

>                                                               Then
> machine-specific optimisation would be easier, amongst other minor benefits
> like slightly smaller code size.  I guess on the other side of the balance
> is the added complexity of the interpreter.

... and the corresponding increased icache burden, and so on.

>> the toolchain (in Sun's case gratuitously different from C compilers and
>> not terribly good at optimization) and the Java libraries (a fucking mess)
>> is important, I think.
>> 
>> (GCJ can, of course, compile to either native code or .class files.)
> 
> I haven't looked into native-code compilation of Java in about seven years
> (it was my thesis topic), and therefore I don't know how gcj does
> native-code compilation,

GCC 3.3: java source -> java trees -> RTL, statement-by-statement -> asm
GCC 3.4: java source -> java trees -> RTL, whole functions at once -> asm
GCC tree-ssa branch (to be 3.5):
         java source -> GIMPLE -> SSAed GIMPLE -> RTL -> asm

(I think I've got the latter right; there may be an un-SSA-back-to-
denormalized-GIMPLE in there, but I don't think so.)

There are optimizations at each stage. (Obviously if you start from
class files instead of Java source, the optimization is less effective
because there's less semantic information available.)

I'm not even going to mention the way gcj compiles to .class files. It's
disgusting. It will die. I vow this. ;}

>                          but IIRC the late binding (that is, for those who
> don't know what I'm talking about, that a method call, for example, is
> referred to *by name* in calling code and only resolved when the call is
> actually made)

Um, actually `by reference' is good enough. Any polymorphic call could
be referred to as being late-bound (although it's true that it rarely is
in Java because *every* call to a non-final method is so bound).

>                basically kills any benefit you might get from compiling a
> class natively.

It certainly doesn't. You JIT-compile the thing when first requested
(after starting the bytecode interpretation, of course), and cache it.
(The HotSpot JVM does exactly this; the `gij' interpreter in libgcj
doesn't bother, because it'd require linking all of GCC into libgcj,
which some people might think was going a bit far.)

-- 
`It is an unfortunate coincidence that the date locarchive.h was
 written (in hex) matches Ritchie's birthday (in octal).'
               -- Roland McGrath on the libc-alpha list

-- 
Gllug mailing list  -  Gllug at linux.co.uk
http://list.ftech.net/mailman/listinfo/gllug