1. 31 Jan, 2018 1 commit
  2. 15 Sep, 2017 1 commit
  3. 14 Sep, 2017 2 commits
    • Mike Hommey's avatar
      Bug 1399921 - Register zone allocator independently, and delay jemalloc... · c53e695a
      Mike Hommey authored
      Bug 1399921 - Register zone allocator independently, and delay jemalloc initialization on mac. r=njn
      
      In bug 1361258, we unified the initialization sequence on mac, and
      chose to make the zone registration happen after jemalloc
      initialization.
      
      The order between jemalloc init and zone registration shouldn't actually
      matter, because jemalloc initializes the first time the allocator is
      actually used.
      
      On the other hand, in some build setups (e.g. with light optimization),
      the initialization of the thread_arena thread local variable can happen
      after the forced jemalloc initialization because of the order the
      corresponding static initializers run. In some levels of optimization,
      the thread_arena initializer resets the value the jemalloc
      initialization has set, which subsequently makes choose_arena() return
      a bogus value (or hit an assertion in ThreadLocal.h on debug builds).
      
      So instead of initializing jemalloc from a static initializer, which
      then registers the zone, we instead register the zone and let jemalloc
      initialize itself when used, which increases the chances of the
      thread_arena initializer running first.
      
      --HG--
      extra : rebase_source : 4d9a5340d097ac8528dc4aaaf0c05bbef40b59bb
      c53e695a
    • Mike Hommey's avatar
      Bug 1399921 - Register zone allocator independently, and delay jemalloc... · 078c8d18
      Mike Hommey authored
      Bug 1399921 - Register zone allocator independently, and delay jemalloc initialization on mac. r=njn
      
      In bug 1361258, we unified the initialization sequence on mac, and
      chose to make the zone registration happen after jemalloc
      initialization.
      
      The order between jemalloc init and zone registration shouldn't actually
      matter, because jemalloc initializes the first time the allocator is
      actually used.
      
      On the other hand, in some build setups (e.g. with light optimization),
      the initialization of the thread_arena thread local variable can happen
      after the forced jemalloc initialization because of the order the
      corresponding static initializers run. In some levels of optimization,
      the thread_arena initializer resets the value the jemalloc
      initialization has set, which subsequently makes choose_arena() return
      a bogus value (or hit an assertion in ThreadLocal.h on debug builds).
      
      So instead of initializing jemalloc from a static initializer, which
      then registers the zone, we instead register the zone and let jemalloc
      initialize itself when used, which increases the chances of the
      thread_arena initializer running first.
      
      --HG--
      extra : rebase_source : 4d9a5340d097ac8528dc4aaaf0c05bbef40b59bb
      078c8d18
  4. 01 Nov, 2017 3 commits
  5. 03 Sep, 2017 1 commit
    • Mike Hommey's avatar
      Bug 1396361 - Avoid crashing when some system library calls malloc_zone_free(zone, NULL). r=njn · acb85e2b
      Mike Hommey authored
      Some system libraries call malloc_zone_free directly instead of free,
      and sometimes they do that with the wrong zone. When that happens, we
      circle back, trying to find the right zone, and call malloc_zone_free
      with the right one, but when we can't find one, we crash, which matches
      what the system free() would do. Except in one case where the pointer
      we're being passed is NULL, in which case we can't trace it back to any
      zone, but shouldn't crash (system free() explicitly doesn't crash in
      that case).
      
      --HG--
      extra : rebase_source : 17efdcd80f1a53be7ab6b7293bfb6060a9aa4a48
      acb85e2b
  6. 04 Jul, 2017 1 commit
    • Mike Hommey's avatar
      Bug 1356701 - Export unprefixed malloc and duplication functions on OSX. r=njn · 19448fe7
      Mike Hommey authored
      Going through the system zone allocator for every call to realloc/free
      on OSX is costly, because the zone allocator needs to first verify that
      the allocations do belong to the allocator it invokes (which ends up
      calling jemalloc's malloc_usable_size), which is unnecessary when we
      expect the allocations to belong to jemalloc.
      
      So, we export the malloc/realloc/free/etc. symbols from
      libmozglue.dylib, such that libraries and programs linked against it
      call directly into jemalloc instead of going through the system zone
      allocator, effectively shortcutting the allocator verification.
      
      The risk is that some things in Gecko try to realloc/free pointers it
      got from system libraries, if those were allocated with a system zone
      that is not jemalloc.
      
      --HG--
      extra : rebase_source : ee0b29e1275176f52e64f4648dfa7ce25d61292e
      19448fe7
  7. 12 May, 2017 1 commit
    • Mike Hommey's avatar
      Bug 1361258 - Use Thread Local Storage in mozjemalloc on mac. r=erahm · fcd9a555
      Mike Hommey authored
      NO_TLS used to be hardcoded on mac because up to 10.6, __thread was not
      supported. Until recently, we still supported for 10.6, and it's not the
      case anymore, so we could make mac builds use __thread.
      
      Unfortunately, on OSX, __thread circles back calling malloc to allocate
      storage on first access, so we have an infinite loop problem here.
      Fortunately, pthread_keys don't have this property, so we can use that
      instead. It doesn't appear to have significantly more overhead (and TLS
      overhead is small anyways compared to the amount of work involved in
      allocating memory with mozjemalloc).
      
      At the same time, we uniformize the initialization sequence between
      mozjemalloc and mozjemalloc+replace-malloc, such that we have less
      occasions for surprises when riding the trains (replace-malloc being
      nightly only), ensuring the zone registration happens at the end of
      mozjemalloc's initialization.
      fcd9a555
  8. 11 May, 2017 1 commit
  9. 05 Apr, 2017 1 commit
  10. 20 Jan, 2017 1 commit
  11. 18 Jan, 2017 4 commits
    • Mike Hommey's avatar
      Bug 1286613 - Add dummy implementations for most remaining OSX zone allocator functions. r=njn · 4e8f02fe
      Mike Hommey authored
      Some system libraries are using malloc_default_zone() and then using
      some of the malloc_zone_* API. Under normal conditions, those functions
      check the malloc_zone_t/malloc_introspection_t struct for the values
      that are allowed to be NULL, so that a NULL deref doesn't happen.
      
      As of OSX 10.12, malloc_default_zone() doesn't return the actual default
      zone anymore, but returns a fake, wrapper zone. The wrapper zone defines
      all the possible functions in the malloc_zone_t/malloc_introspection_t
      struct (almost), and calls the function from the registered default zone
      (jemalloc in our case) on its own. Without checking whether the pointers
      are NULL.
      
      This means that a system library that calls e.g.
      malloc_zone_batch_malloc(malloc_default_zone(), ...) ends up trying to
      call jemalloc_zone.batch_malloc, which is NULL, and crash follows.
      
      So as of OSX 10.12, the default zone is required to have all the
      functions available (really, the same as the wrapper zone), even if they
      do nothing.
      
      This is arguably a bug in libsystem_malloc in OSX 10.12, but jemalloc
      still needs to work in that case.
      
      [Adapted from
      https://github.com/jemalloc/jemalloc/commit/c6943acb3c56d1b3d1e82dd43b3fcfeae7771990]
      
      --HG--
      extra : rebase_source : 7d7a5b47fa18f56183e99c3655aee003c9be161e
      4e8f02fe
    • Mike Hommey's avatar
      Bug 1286613 - Don't rely on OSX SDK malloc/malloc.h for malloc_zone struct definitions. r=njn · dae510ad
      Mike Hommey authored
      The SDK jemalloc is built against might be not be the latest for various
      reasons, but the resulting binary ought to work on newer versions of
      OSX.
      
      In order to ensure this, we need the fullest definitions possible, so
      copy what we need from the latest version of malloc/malloc.h available
      on opensource.apple.com.
      
      [Adapted from
      https://github.com/jemalloc/jemalloc/commit/c68bb4179312665e22d375aecf9f4306607c7c1a]
      
      --HG--
      extra : rebase_source : ab19c478b568ea24095a3be62c39fb81efc1920a
      dae510ad
    • Mike Hommey's avatar
      Bug 1286613 - Use the same zone allocator implementation as replace-malloc for mozjemalloc. r=njn · e52769e8
      Mike Hommey authored
      We have been using a different zone allocator between mozjemalloc and
      replace-malloc for a long time. Jemalloc 4 uses the same as
      replace-malloc, albeit as part of the jemalloc upstream code base.
      
      We've been bitten many times in the past with Apple changes breaking the
      zone allocator, and each time we've had to make changes to the three
      instances, although two of them are similar and the changes there are
      straightforward.
      
      It also turns out that the way the mozjemalloc zone allocator is set up,
      when a new version of OSX appears with a new version of the system zone
      allocator, Firefox ends up using the system allocator, because the zone
      allocator version is not supported.
      
      So, we use the same zone allocator for both replace-malloc and
      mozjemalloc, making everything on par with jemalloc 4.
      
      --HG--
      extra : rebase_source : 9c0e245b5f82bb71294370d607e690c05cc89fbc
      e52769e8
    • Mike Hommey's avatar
      Bug 1286613 - Move replace-malloc zone allocator to a separate file. r=njn · d293cc01
      Mike Hommey authored
      The intent here is to reuse the zone allocator for mozjemalloc, to avoid
      all the shortcomings of mozjemalloc using a different one. This change
      only moves the replace-malloc zone allocator out of replace-malloc.c, to
      make changes for mozjemalloc integration clearer.
      
      --HG--
      rename : memory/build/replace_malloc.c => memory/build/zone.c
      extra : rebase_source : 8b98efaa4a88862f2967c855b511e92beb9c4031
      d293cc01
  12. 19 Jan, 2017 1 commit
    • Mike Hommey's avatar
      Bug 1286613 - Properly call mozjemalloc pre/post fork hooks on OSX when... · 50dd84a5
      Mike Hommey authored
      Bug 1286613 - Properly call mozjemalloc pre/post fork hooks on OSX when replace-malloc is enabled. r=njn
      
      Somehow, we never called those hooks when replace-malloc is enabled. I'd
      expect this to cause random deadlocks when forking, and I'm surprised
      this hasn't surfaced. Maybe it actually causes some intermittent oranges
      on automation, who knows.
      
      This also brings consistency with what is done for jemalloc 4, and with
      the mozjemalloc implementation, too, that we're going to replace with
      this one in a subsequent changeset.
      
      --HG--
      extra : rebase_source : 059567d17f928098db8367e9081b631ced351110
      50dd84a5
  13. 23 Aug, 2016 1 commit
  14. 16 Aug, 2016 1 commit
  15. 12 Aug, 2016 1 commit
  16. 08 Jul, 2016 1 commit
  17. 01 Feb, 2016 1 commit
  18. 18 Nov, 2014 1 commit
  19. 02 Jul, 2014 1 commit
  20. 11 Jun, 2014 1 commit
  21. 24 Oct, 2014 1 commit
  22. 07 Dec, 2012 1 commit