SV: generic type support

[Øyvind Harboe <oyvind dot harboe at zylin dot com>]

>Yes, but we optimize better from source and we remove one unnecessary
>compilation step.  Also, the debugging information in byte compiled
>files isn't so very good -- you lose full pathnames for example.

These are convincing arguments. If the resources are there to create
a good frontend that keeps up, it's definitely a boon.

> > I'm not clear on what the design goals for GCJ is, but my vote is
> > for deployment: Java could get a bigger bite out of the desktop, if
> > applications didn't have to drag along the JRE with all its
> > hickups.
>
>You can't do anything about that because of the way the language is
>defined.  There always must be a runtime environment, because it's
>part of the specification.

I suppose when I say that GCJ does not come with a JRE, its more correct
to say that it does not come with any of the annoying quirks that the Sun JRE 
comes with:

- Side by side installation pains
- Large download size
- The installation can screw up your machine, e.g. there is a Norwegian banking Java Applet that stops working after  JRE 1.4.1 is installed. Blame games aside, this problem does not exist with my GCJ compiled app. 

> > Development efforts aside, I believe that a JIT compiler could
> > be made to outdo any source level static compiler.
>
>Because?  I know that the IBM JIT performance is very good, but I
>think gcj can do even better.

First of all: I concede that the bytecode format is not quite as compiler friendly as it could be. I browsed through the bytecode format of MSIL(.Net) and they include compiler hint instructions, e.g. SSA(single static assignment), looping hints, etc. Datatypes for vector instructions are missing. I suppose vector instructions have been "outflanked" by graphics cards, and hence MSIL does not include them even if it was defined years after Java bytecode. 

A list of weapons available to a JIT compiler:

- Static compilation from bytecode at install time: the native code can take advantage of CPU specific instructions. Move conditionals, cache sizes, vector instructions, alignment rules, scheduling, etc.
- Profiling based compilation: spend compilation time where it does good
- Speculative compilation: based upon profiling information, create versions of functions based upon actual arguments/instantiations.

I'm taking the liberty of broadening the definition of a JIT to include installation time compilation, optimisation during idle time of the computer, etc. 

Øyvind