Interesting paper on Supporting Binary Compatibility with Static Compilation

Sun Aug 18 20:50:00 GMT 2002

Jeff Sturm wrote:
>>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.
>>>>>>It should improve, actually. Same for memory footprint. Right
>now gcj does quite poorly on both, especially for DSOs.
>>For example: -findirect-dispatch defers vtable construction, eliminating a
>good number of symbolic relocations per class. But unfortunately the
>offset table adds even more absolute relocations. So the improvement is
>marginal, if any.
>>That isn't hard to fix for indirect dispatch, because the vtable is part
>of the ABI, whereas the offset table isn't. Just choose another otable
>layout that doesn't require linking pointers.
>
Its actually sort of the opposite for indirect dispatch. The otable 
becomes part of the ABI because the otable compiled into each 
application must match what libgcj is expecting when it loads/links a 
class. Because vtables are constructed at run time, the layout of 
vtables could be changed if all object files in the application were 
compiled with --indirect-dispatch.
I'd be interested in any suggestions for a better otable design that 
doesn't require pointers, without sacrificing too much space. The 
current design is fairly compact because the class/method/signature 
strings are uniqued/merged automatically with any other instances in the 
same .so, including the reflection data. Its also fairly simple and easy 
to work with!
regards
Bryce.