|TOPLAS: Linking Programs Incrementally email@example.com (John R. Levine) (1991-03-15)|
|Re: TOPLAS: Linking Programs Incrementally firstname.lastname@example.org (1991-03-23)|
|From:||email@example.com (Marc Sabatella)|
|Organization:||Hewlett-Packard, Fort Collins, CO, USA|
|Date:||23 Mar 91 00:07:54 GMT|
>The January TOPLAS has an interesting article by Russell Quong and Mark Linton
>on incremental linking.
This was, as noted, rather old work; we have it as a Stanfaord technical
report dated December 1987 (CSL-TR-87-341).
There is also an article on "SunPro: Engineering A Practical Program
Development Environment" in "Advanced Programming Environments.
Proceedings Of An International Workshop" by Adamsm Gramlich, Muchnick,
and Tirfing; this is dated even earlier (1986). The implementation of
incremental linking was discussed only peripherally. The basic idea
seemed to be to use slop, as in Quong and Linton's work, but rather than
keep relocation and other information necessary for quick updates in
memory, it appears to be stored in the executable file. This seems
reasonable to me: the data in memory was probably going to to be swapped
out anyhow, and this made it easier to work in a clustered or NFS
environment, when you can't guarantee all links would be on the same
machine. It would also work across reboots.
I tried prototyping something along the same lines as my interpretation of
SunPro. I saw improvements more or less like Quong and Linton did in the
non-overflow case (albeit with slightly more overhead, as I had to re-read
and parse the symbol table and associated relocation tables), but in the
overflow case, I got little improvement. This was probably because Quong
and Linton actually kept the entire program's text and data in memory, so
in the case of overflow, there was no need to re-read the .o's that had
not changed, whereas I still had to go back and re-read them, or at least
re-read the original executable.
Marc Sabatella (firstname.lastname@example.org)
Return to the
Search the comp.compilers archives again.