<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 24, 2018 at 12:10 PM, Frederik Deweerdt <span dir="ltr"><<a href="mailto:frederik.deweerdt@gmail.com" target="_blank">frederik.deweerdt@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 class="">On Wed, Jan 24, 2018 at 11:30 AM, Kostya Serebryany <<a href="mailto:kcc@google.com">kcc@google.com</a>> wrote:<br>
> +Aleksey, who has been dealing with the allocator recently.<br>
><br>
> If you have a "((idx)) < ((kMaxNumChunks))" (0x40000, 0x40000)<br>
> check failure, it means that you've allocated (and did not deallocate) 2^18<br>
> large heap regions, each *at least* (2^17+1) bytes.<br>
> This means, that you have live large heap chunks of 2^35 bytes (or more) in<br>
> total, which is 32Gb.<br>
> Does this sound correct?<br>
</span>Yes, it does. Our software typically allocates several hundred Gb, and<br>
the size of the objects depend on the traffic. They would<br>
realistically reach 2^17+1 bytes.<br>
<span class=""><br>
> If yes, yea, I guess we need to bump kMaxNumChunks<br>
><br>
><br>
</span>I'll increase the limit to 2^19 for our build, and I'll report the results here.<br></blockquote><div><br></div><div>Yes, please do. Thanks! </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thanks,<br>
Frederik<br>
</blockquote></div><br></div></div>