<html>

  <head>

    <meta content="text/html; charset=windows-1252"

      http-equiv="Content-Type">

  </head>

  <body bgcolor="#FFFFFF" text="#000000">

    <div class="moz-text-html" lang="x-western"> <br>

      <div class="moz-cite-prefix">On 06/01/2017 02:50 AM, Antoine

        Pitrou wrote:<br>

      </div>

      <blockquote cite="mid:20170601115014.18dcb755@fsol" type="cite">

        <pre wrap="">Another possible strategy is: allocate several arenas at once (using a

larger mmap() call), and use MADV_DONTNEED to relinquish individual

arenas.

</pre>

      </blockquote>

      <br>

      Thus adding a *fourth* layer of abstraction over memory we get

      from the OS?<br>

      <blockquote>block -> pool -> arena -> "multi-arena" ->

        OS<br>

      </blockquote>

      Y'know, this might actually make things faster.  These

      multi-arenas could be the dynamically growing thing Victor wants

      to try.  We allocate 16mb, then carve it up into arenas (however

      big those are), then next time allocate 32mb or what have you. 

      Since the arenas remain a fixed size, we don't make the

      frequently-used code path (address_in_range) any slower.  The code

      to deal with the multi-arenas would add a little complexity--to an

      admittedly already complex allocator implementation, but then what

      allocator isn't complex internally?--but it'd be an infrequent

      code path and I bet it'd be an improvement over simply calling

      malloc / mmap / VirtualAlloc.  What do you think, Victor?<br>

      <br>

      And to think I started this reply ironically,<br>

      <br>

      <br>

      <i>/arry</i><br>

    </div>

  </body>

</html>