<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div class="gmail-HOEnZb"><div class="gmail-h5"><br>
</div></div>I've raised the concern about problems with this approach in<br>
multithreaded environment, but this particular tool is a good example,<br>
so we can discuss those problems here.<br>
Your approach suggests storing the state of 512 cache lines in a<br>
single shadow cache line. So, if I'm understanding the algorithm<br>
correctly, parallel accesses to 512 adjacent cache lines from<br>
different CPUs will cause unnecessary contention on that shadow cache<br>
line, which will presumably degrade the application's performance.<br>
Also note that because we don't have atomic bitwise operations,<br>
updates of shadow bytes will require a CAS loop.<br>
I'm not sure about the performance impact of the above issues, but<br>
there might be a tradeoff between the shadow memory scale and the<br>
slowdown.<br></blockquote><div><br></div><div>1. As Derek said, we will do 64B-2-1B mapping for easier instrumentation.</div><div>2. The cache contention in fact is not as bad as you think if we apply the optimization mentioned by Derek:</div><div>"<span style="font-size:12.8px">1) Add a shadow bit check before writing each bit to reduce the number of memory stores.  In our experience this is always a win with shadow memory tools.</span>"</div><div>By doing that, most shadow access would be read instead of write, so much less cache contention.</div></div></div></div>