SV: generic type support

[Andrew Haley]

=?iso-8859-1?Q?=D8yvind=5FHarboe?= writes:
 > 
 > >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.

We can do that too.  It's nothing to do with JIT compilation.

 > - Profiling based compilation: spend compilation time where it does
 > good

We can even do that for C.  We should do more.

 > - Speculative compilation: based upon profiling information, create
 > versions of functions based upon actual arguments/instantiations.

That too.

True, profile feedback optimization requires more intervention in a
precompiled environment.  On the other hand, we have far more power in
an ahead of time compiler than any sane person would want in a JIT.
Eventually, if you have all that functionality in a JIT, it will be
just as big and just as slow as the ahead of time compiler.

 > 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.

Well, then it's not a JIT.  It's an ahead of time compiler.

Andrew.