[m-dev.] Deep.data and Deep.procrep

[Paul Bone]

Hi Guys.

I've just been chasing a bug that didn't exist.  However I shouldn't have been
chasing it.  I'm therefore looking for suggestions about how to prevent this.

Background:  Programs compiled for deep profiling produce a Deep.data file in
the current directory after they finish.  This file contains the profile.  The
automatic parallelism analysis also requires a Deep.procrep file which can be
written out of the executable is invoked with --deep-procrep-file in the
MERCURY_OPTIONS environment variable.  This file contains a bytecode
representation of the program.  These files must match, that is the same
executable must generate both files, but it is possible to use files generated
on different profiling runs since the Deep.procrep file is always identical for
the same executable.

So I was chasing a crash in the automatic parallelism analysis that was caused
by using a different but similar Deep.procrep file.  What I would like is a way
for the analysis tools (including mdprof_cgi) to assert that the Deep.data and
Deep.procrep files match (where generated from the same executable) before
doing any processing.

I have a couple of ideas, and I'd like to hear anyone else's ideas:

  1. When the runtime writes out the data, it should generate a pseudo-random
     number and include it in the headers of both files.  Upon reading both
     files check that the numbers match.

     Cons: A little too strong, this means writing out the Deep.procrep file
           every time the executable is executed.

  2. Store a hash of the Deep.procrep file inside the Deep.data file so that
     the hash can be compared against the data when reading the files.

     Cons: More difficult.

     Cons; Computing the hash might take just as long as writing out the data
           every time the program is executed.

  3. The same as 2 except that the hash (and the Deep.procrep data) could be
     computed at link time.

     Cons: More difficult compared to 2.

     Pros: The procrep data could be removed from the executable, making it
           smaller.

  4. Include the procrep data inside the Deep.data.

     Cons: Simpler from the user's perspective.
     
     Cons: The procrep data must be written out every time the program is executed.

  5. In combination with any of the above, the procrep data could be
     compressed, either at compile, link or run-time.

     Pros: This means storing less data (for example in the files and possibly
           the executable.

Thanks.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: <http://lists.mercurylang.org/archives/developers/attachments/20100803/d69c9d9d/attachment.sig>