SV: generic type support

[Øyvind Harboe]

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

Would you compile one executable per cpu configuration?


Not very convenient from a deployment point of view. One complation for ecah of the configurations below:


- 486
- 586
- MMX
- MMX + SSE
- 3D Now! + MMX
- 3D Now! + SSE
- MMX + SSE + SSE2

+++


> > - Profiling based compilation: spend compilation time where it does
> > good
>
>We can even do that for C.  We should do more.

The problem is that the profiling pattern is not known before the application is deployed. The profiling pattern changes with data processed. Admittedly profiling on development machine 
covers a lot of this ground.



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

How about:

E.g.

// this sort of optimisation is probably most useful in combination with
// vector instructions
void calcsome(int c, int d)
{
  for(int i=0; i<c; i++)
{
  foobar[i]/=d;
}
}

A JIT profiler could discover that the following were common, based upon actual data processed:

- calcsome(4, d) -> unrolled (single vector instruction on SSE2).
- calcsome(c, 1) -> no-op
- calcsome(c, 2525) -> multiply by inverse
- calcsome(3, 7) -> perhaps completely unrolled and inlined


If you have a callgraph:

  foo(c,d)->bar(c,d)->calcsome(c,d)
   

The JIT profiler/compiler would know where to start generating special versions.



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

There is a spectrum of approaches between AOT and JIT. AOT during
installation, is nifty. (Or overnight after installation).

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

OK. In which case I'm in favour of the JRE doing more profiling + AOT.

GCJ AOT and JRE AOT differ significantly though.

Øyvind