SV: generic type support

Thu Feb 20 11:27:00 GMT 2003

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

>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)?

The best possible performance could be had if source compilation happened AOT 
with profiling information specific to deployment hardware and data to be processed.

I suppose bytecode gives a bit better IP protection than handing out source code,
and more actual work has been done in bytecode to native on deployment machine
than source to native. Unix has done source on deployment machines since forever
though.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gcc.gnu.org/pipermail/java/attachments/20030220/23478222/attachment.htm>