Skip to content
  1. Nov 07, 2016
  2. Nov 04, 2016
  3. Nov 03, 2016
  4. Nov 02, 2016
    • Jason Evans's avatar
      Force no lazy-lock on Windows. · eee1ca65
      Jason Evans authored
      Monitoring thread creation is unimplemented for Windows, which means
      lazy-lock cannot function correctly.
      
      This resolves #310.
      eee1ca65
  5. Nov 01, 2016
  6. Oct 31, 2016
  7. Oct 30, 2016
  8. Oct 29, 2016
    • Jason Evans's avatar
      Do not mark malloc_conf as weak on Windows. · 1dcd0aa0
      Jason Evans authored
      This works around malloc_conf not being properly initialized by at least
      the cygwin toolchain.  Prior build system changes to use
      -Wl,--[no-]whole-archive may be necessary for malloc_conf resolution to
      work properly as a non-weak symbol (not tested).
      1dcd0aa0
    • Jason Evans's avatar
      Do not mark malloc_conf as weak for unit tests. · 6ec2d8e2
      Jason Evans authored
      This is generally correct (no need for weak symbols since no jemalloc
      library is involved in the link phase), and avoids linking problems
      (apparently unininitialized non-NULL malloc_conf) when using cygwin with
      gcc.
      6ec2d8e2
    • Dave Watson's avatar
      Support static linking of jemalloc with glibc · 83093884
      Dave Watson authored
      glibc defines its malloc implementation with several weak and strong
      symbols:
      
      strong_alias (__libc_calloc, __calloc) weak_alias (__libc_calloc, calloc)
      strong_alias (__libc_free, __cfree) weak_alias (__libc_free, cfree)
      strong_alias (__libc_free, __free) strong_alias (__libc_free, free)
      strong_alias (__libc_malloc, __malloc) strong_alias (__libc_malloc, malloc)
      
      The issue is not with the weak symbols, but that other parts of glibc
      depend on __libc_malloc explicitly.  Defining them in terms of jemalloc
      API's allows the linker to drop glibc's malloc.o completely from the link,
      and static linking no longer results in symbol collisions.
      
      Another wrinkle: jemalloc during initialization calls sysconf to
      get the number of CPU's.  GLIBC allocates for the first time before
      setting up isspace (and other related) tables, which are used by
      sysconf.  Instead, use the pthread API to get the number of
      CPUs with GLIBC, which seems to work.
      
      This resolves #442.
      83093884
  9. Oct 28, 2016