Changes between Version 9 and Version 10 of Commentary/Compiler/RecompilationAvoidance

Dec 5, 2007 1:19:31 PM (6 years ago)



  • Commentary/Compiler/RecompilationAvoidance

    v9 v10  
    312312== Alternative design choices == 
    314 === fingerprints instead of versions === 
    316 === module-granularity instead of declaration-granularity === 
     314=== Fingerprints instead of versions === 
     316Version numbers in this context have a couple of problems: 
     318 * New version numbers are calculated from the old version numbers, so we have to 
     319   keep the old interface around to generate the new one.  (but we need to keep 
     320   the old interface around anyway, because we might avoid touching it if it 
     321   doesn't change). 
     323 * Removing an interface file can have disastrous effects, as all its version 
     324   numbers will be reset when it is next compiled.  To be fair, this doesn't seem 
     325   to affect many people (that we know of). 
     327 * We want to detect changes in package dependencies (see #1372): right now, we only 
     328   record a dependency on the package.  The right thing to do is to record a dependency 
     329   on the module that we import, so we can detect when it changes.  But packages are 
     330   generally compiled from scratch and then installed, so typically all the version 
     331   numbers will be 1, and our dependency is not telling us when the package has changed. 
     333Using fingerprints or hashes instead of version numbers is morally the right thing to do.  A fingerprint can be calculated independently of the previous version of the interface interface, and it solves the package dependency problem. 
     335=== Module-granularity instead of entity-granularity === 
     337Fingerprints or hashes are larger than version numbers (typically 128 bits instead of 32), so we might not want to put a fingerprint on every entity. 
     339Also, it's worth thinking about whether tracking changes at a lower level of granularity would result in a system that is simpler to implement, understand, and get right.  The obvious choice is to track modules instead of entities.  Clearly this loses some resolution, and will therefore entail more unnecessary recompilation, but how much?  Let's look at how it would work, and then some examples. 
     341Every module will have a single version number (or fingerprint), which is increased whenever there is a change to either the exports or the decls (but not the usages) in the interface, or the version of any module referred to by the exports or decls changes.  The usages of the module lists the modules and versions referred to by the source code (as before, except that we only record modules not entities).