Re: [Valgrind-developers] binary code optimization

[Nuno L. <nun...@sa...>]

Thanks for the answers!

>>  - How did valgrind handle the case when a block is removed from the 
>> cache
>> and it has other blocks that jump directly into it (i.e. blocks that were
>> previously patched)? Did valgrind purged the whole cache? Did it scanned
>> the remaining blocks for references and "unpatched" blocks?
>
> Honestly .. I can't remember.  But you ask the right questions at least;
> this is the #1 hard problem with chaining.  Read the 2.4 sources ...

Ok, so as far as I understood, the cache is divided in 8 sectors, which are 
managed in a FIFO way. When the oldest sector is purged, it searches all the 
others sector's blocks for patched jumps and unpatches thems. This can be a 
good solution if the cache is not purged very often, otherwise the cost may 
be prohibitive (where adding a little table to each superblock with 
back-pointers to referencing blocks would perform better, or Josef's idea in 
the other e-mail as well). Do you have any stats to confirm if's that the 
case? I dunno about the perftests, but I assume they are so small they don't 
even fill up the whole cache, right?


> btw, for lots of background on code cache management, you might be
> interested to read Kim Hazelwood's PhD thesis:
> http://www.cs.virginia.edu/kim/docs/phd-thesis.pdf

Out of curiosity: why did you change from FIFO to LRU in valgrind 3? I'm 
only asking this because that thesis suggests that FIFO may be better.


Thanks,
Nuno