SV: generic type support

[Øyvind Harboe]

> > The problem is that the profiling pattern is not known before the
> > application is deployed. The profiling pattern changes with data
> > processed.
>
>In which case profile directed optimization is invalid, because the
>profile might equally well be wrong for the next run of data.  Profile
>directed optimization pretty much assumes that the pattern of usage is
>consistent between runs.

The idea is that the profiling/JIT process is an iterative process. 

However, I don't want to give up profiling on development machine just because I have
profiling on the deployment machine. Also, the profiling/JIT process could benefit
from being explicitly directed by the programmer.

E.g. Lets say a flag was added to Java bytecode

void __reallyoptimizethisoneidontcarehowlongittakes foo() {}

 
>With regard to getting the best performance from a specific chip,
>there seems to be a choice here:
>
>  a) Compile from bytecode during installation.
>  b) Compile from source during installation.
>
>  ... and then perhaps recompile with profile directed optimization.
>  Alternatively, a profile could be delivered with the application.
>
>Why will a) necessarily be better than b)?

Sourcecode has all the information that the bytecodes contain + more. Sourcecode is
better input to the compiler, no argument from me on that one.

Why do we have bytecodes at all? 

- Less work happens on deployment machine
- IP protection

Unix has done source to native compilation on deployment machines since forever.