Re: TOPLAS: Linking Programs Incrementally

mjs@hpfcso.fc.hp.com (Marc Sabatella)
23 Mar 91 00:07:54 GMT

          From comp.compilers

Related articles
TOPLAS: Linking Programs Incrementally johnl@iecc.cambridge.ma.us (John R. Levine) (1991-03-15)
Re: TOPLAS: Linking Programs Incrementally mjs@hpfcso.fc.hp.com (1991-03-23)
| List of all articles for this month |

Newsgroups: comp.compilers
From: mjs@hpfcso.fc.hp.com (Marc Sabatella)
Keywords: linker, performance
Organization: Hewlett-Packard, Fort Collins, CO, USA
References: <1991Mar21.141616.5721@iecc.cambridge.ma.us>
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 (marc@hpmonk.fc.hp.com)
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.