Announcement

Collapse
No announcement yet.

Jemalloc 5.3 Released With Many Speed & Space Optimizations

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Originally posted by bug77 View Post

    That info needs more context to be relevant. It is possible for an allocator to reserve memory in advance when it detects frequent allocations. It will use more memory, but in doing so it may also dramatically improve throughput.

    "More than good enough" is probably a reference to most apps that are not actually memory intensive.
    And people give shit on GCs that do the same thing to increase throughput (turns out a lot of people still do not know that malloc is not free and RAII has its issues)

    Comment


    • #22
      Originally posted by zboszor View Post

      With certain applications (no swap, limited memory), it is beneficial to get NULL for allocation failures instead of getting a valid pointer and driving the system into OOM. But apparently the other side of the use case spectrum (bigmem, lot of memory hogs and users) disabling memory overcommit is also a solution.
      Arguably, overcommit helps in some no swap, limited memory scenarios, so I'd need something more specific to get the use case (note, OP did have a good reason: they tried empirically on their clusters and it helped). Why do I say it may help? Some applications, some I actually crossed, allocate more than they actually use. Overcommit goes hand in hand with lazy commit, which for those scenarios means "don't waste the memory". You can't have lazy commit without overcommit (or rather, the only thing it changes is you have unpredictable latency on page fault), so you will always use as much as the application asked for. Sometimes the allocator itself may ask for more than it needs in terms of address space.
      What I'm curious is what kind of application actually benefits from disabling it. No doubt some do, but I wanted more concrete examples.

      Regarding "driving the system into OOM", there are other mechanisms to avoid that. If you got that NULL pointer you're there already anyway, and approached it faster due to forcing the allocations eagerly. I've actually been there because I thought it could help my use case at a previous job.

      Comment


      • #23
        Originally posted by mdedetrich View Post

        And people give shit on GCs that do the same thing to increase throughput (turns out a lot of people still do not know that malloc is not free and RAII has its issues)
        Tbh, proper allocation is just impossible to treat in a generic way and still end up with best results. Irl it's probably the primary candidate for PGO.

        Comment

        Working...
        X