Interesting paper on Supporting Binary Compatibility with Static Compilation

[Bryce McKinlay]

Andrew Haley wrote:

>Mark Wielaard writes:
> > http://flint.cs.yale.edu/flint/publications/bincomp.html
> > Supporting Binary Compatibility with Static Compilation
> > Dachuan Yu, Zhong Shao, Valery Trifonov
> > Department of Computer Science, Yale University
>

Thanks for posting that, Mark. I hadn't seen the final version of the 
paper. It is definately essential reading for anyone trying to 
understand the issues with binary compatibility.

>2% of _total_ runtime?  That seems like an awful lot.  Still, if it's
>needed to achieve binary compatibility I suppose we'll have to live
>with it.  However, given my current interest in improving run-time
>performance I don't like to see regressions.
>

A ~2% slow down was the worst case measured for the Java Grande 
benchmarks, for an application whose runtime is particularly dominated 
by virtual dispatch. Some of the benchmarks actually speed up with 
indirect dispatch. I would expect a modest performance hit once binary 
compatiblity for fields is implemented however, if the application 
frequently references fields across different compilation units.

>Also, one of the great advantages of ahead-of-time compilation is fast
>startup; we don't want to lose too much of that either.  I wonder how
>much of this could be done at like time.
>

I think that binary compatibility will actually reduce the start-up 
time. Indirect dispatch moves much of the work of symbolic linking from 
the system's dynamic linker to the libgcj class loader/linker, which can 
be more efficient because the linking is only done for classes actually 
loaded, rather than for every class. As Jeff pointed out there are still 
a lot of absolute relocations - data section relocations within the same 
.so, but these are processed a lot quicker than symbol relocations on linux.

regards

Bryce.