<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Apr 18, 2014 at 1:21 PM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="">On Fri, Apr 18, 2014 at 2:10 AM, Kostya Serebryany <span dir="ltr"><<a href="mailto:kcc@google.com" target="_blank">kcc@google.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">One more proposal: simple per-thread counters allocated with mmap(MAP_NORESERVE), the same trick that works so well for asan/tsan/msan.<div>

<br></div><div>Chrome has ~3M basic blocks instrumented for coverage, </div>
<div>so even largest applications will hardly have more than, say, 10M basic blocks</div></div></blockquote><div><br></div></div><div>I think this is a *gross* underestimation. I work with applications more than one order of magnitude larger than Chrome.</div>
</div></div></div></blockquote><div><br></div><div>Agree, Chrome is comparatively small. But the thing does not change even if we have 100M basic blocks. </div><div>The hypothesis (which need to be checked) is that every thread will touch a small portion of BBs => a small portion of pages in the counter array.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="">
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>(number can be configurable at application start time). This gives us 80Mb for the array of 64-bit counters. </div>

<div>That's a lot if multiplied by the number of threads, but the MAP_NORESERVE trick solves the problem -- </div>
<div>each thread will only touch the pages where it actually increment the counters. </div><div>On thread exit the whole 80Mb counter array are will be merged into a central array of counters and then discarded, </div><div>


but we can also postpone this until another new thread is created -- then we just reuse the counter array. </div><div><br></div><div>This brings two challenges. <br></div><div><br></div><div>#1. The basic blocks should be numbered sequentially. I see only one way to accomplish this: with the help of linker (and dynamic linker for DSOs).</div>


<div>The compiler would emit code using offsets that will later be transformed into constants by the linker. </div><div>Not sure if any existing linker support this kind of thing. Anyone? </div><div><br></div><div>#2. How to access the per-thread counter array. If we simply store the pointer to the array in TLS, the instrumentation will be more expensive just because of need to load and keep this pointer. </div>


<div>If the counter array is part of TLS itself, we'll have to intrude into the pthread library (or wrap it) so that this part of TLS is mapped with MAP_NORESERVE. </div></div></blockquote><div><br></div></div><div>#3. It essentially *requires* a complex merge on shutdown rather than a simple flush. </div>
</div></div></div></blockquote><div>yep</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div>I'm not even sure how to do the merge without dirtying still more pages of the no-reserve memory.</div></div></div></div></blockquote><div>and yep again. I don't know a way to check if a mmaped page is unused. </div>
<div><br></div><div>--kcc </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div><br></div><div><br></div><div>It's not at all clear to me that this scales up (either in memory usage, memory reservation, or shutdown time) to larger applications. Chrome isn't a useful upper bound here.</div>

</div></div></div>
</blockquote></div><br></div></div>