<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Apr 20, 2016 at 1:15 PM, Filipe Cabecinhas <span dir="ltr"><<a href="mailto:filcab@gmail.com" target="_blank">filcab@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Wed, Apr 20, 2016 at 6:44 AM, Derek Bruening via llvm-dev<br>
<<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
> We will divide the program execution into regular intervals and record a<br>
> snapshot of the working set at each interval boundary.  An adaptive strategy<br>
> can keep the number of snapshots bounded across varying total execution time<br>
> by combining adjacent snapshots via logical or.  When a snapshot is<br>
> recorded, the shadow memory is cleared so that the next snapshot starts with<br>
> a blank slate.  If we use a 64 byte to 1 byte shadow mapping, we can use the<br>
> upper bits to store up to 8 consecutive snapshots in the shadow memory<br>
> itself by shifting rather than clearing the shadow memory on a snapshot.<br>
</span>I forgot to add my previous questions:<br>
<br>
About the working set tool:<br>
How are you thinking about doing the snapshots? How do you plan to<br>
sync the several threads?<br>
Spawning an external process/"thread" (kind of like LSan), or internally?<br>
<br>
I know I'm getting to low(ish)-level details, but if you've already<br>
thought about this (possibly about several ways to do this), I'd like<br>
to know more about what avenues you're planning on exploring.<br>
<br>
I'm ok with a "we haven't thought that far ahead about this tool yet" :-)<br></blockquote><div><br></div><div>Our plan is to live with races between shadow memory updates in other threads and the thread making a copy of the shadow memory.  The nature of the tool means that pinpoint accuracy is not required.</div></div></div></div>