Wednesday, July 26, 2006


Eiffel Shared Libraries and Incremental Compilation

As a previous C user, and now addicted Eiffel user, I have been thinking about and working on improvements in Eiffel tools and libraries, and I think that there are some aspects of C program building that Eiffel should adopt.

I wish Eiffel to be seen as a possible primary language choice, not just for single, isolated, projects but for all-encompassing packages like KDE/Gnome etc, and there is one major roadblock in the way of that choice.

Some 20 years ago, it was recognized that with all programs being statically linked, the file system and RAM/Swap have needless duplication of identical code for each of thousands of distinct programs. This is a performance issue, in that for most programs the library code is most of the application, say 80%, so that a given size of RAM can support 4-5 times the number of processes (not swapping) with shared libraries than it could without.

There is a performance loss, for a single program, in using shared library technology, but the gain in loading from disk only the 20% of code not in the library is substantial.

Once multiple shared libraries are available, then the following is feasible:

Load library L1, containing classes A, B, C etc
Load library L2, containing (updated) class B
Register classes from library L1
Register classes from library L2, overriding/hiding class B in L1
For each registered class, allocate class IDs and register routines and attribute offsets etc
Proceed through creation of root class instance ...

The above provides for incremental compilation during program development, enables libraries to be shared by distinct programs, and makes possible the dynamic loading at run-time of additional libraries containing classes that inherit from classes present in the base library class set, making possible what is now possible in Java but not in Eiffel.

I think there are lessons to learn from what has been achieved with C/C++/Java infrastructure, if not from their syntax and semantics! Let the discussion commence...

The lesson I've learned is that tracking down dependencies, latest versions, fixing C code because newer or older C compilers don't like the particular syntax is a time consuming task.
Well I have used C since 1976, and Eiffel since 1993, and compiler syntax changes and library dependencies have been just as omni-present with Eiffel as with C. Eiffel tools are better, at least in some respects, but could be much better still. I think that tool quality, functionality, and availability are determining factors in Eiffel being chosen, or not chosen, as a project language.
Howard, I wasn't claiming Eiffel did better here :-)

I think the problem itself is hard. It isn't solved. And static linking has a lot of advantages IMO.

Dynamic linking has two advantages: memory usage and that you've to update only one lib in case of a security risk and update a whole lot of applications.

Hard disk usage isn't an issue these days. Memory usage perhaps still is. And security, I don't know, for Eiffel apps it wouldn't be such an issue.
Post a Comment

<< Home

This page is powered by Blogger. Isn't yours?