This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Interesting paper on Supporting Binary Compatibility with StaticCompilation


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.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]