Upgrade jemallocator

[jtgeibel]

Background threads are now enabled for all artifacts by enabling the
background_threads feature.

Reviewing jemalloc-sys shows the underlying jemalloc version remains
unchanged at 5.1, so this is not expected to affect runtime behavior in
production.

Refs: #1265

[rust-highfive]

r? @smarnach

(rust_highfive has picked a reviewer for you, use r? to override)

[smarnach]

Background threads are now enabled for all artifacts by enabling the
background_threads feature.

This looks like a questionable design choice, since you basically don't have any way to make sure no background threads are used – features are additve and could be enabled by any transitive dependency. It may make sense in this particular case, and it's definitely not a problem for us, since making sure that a feature i enabled is easy.

@bors r+

[bors]

📌 Commit 8671445 has been approved by smarnach

[bors]

⌛ Testing commit 8671445 with merge a7a40ff...

[bors]

☀️ Test successful - checks-travis
Approved by: smarnach
Pushing a7a40ff to master...

[carols10cents]

Errrr when I try to run the server locally with this PR on macOS, I get:

$ cargo run --bin server
    Finished dev [unoptimized + debuginfo] target(s) in 0.51s
     Running `target/debug/server`
<jemalloc>: option background_thread currently supports pthread only
memory allocation of 40 bytes failedAbort trap: 6

Looking into this now to see if this is a personal problem...

[ehuss]

background_threads is not supported on macOS (jemalloc/jemalloc#1433). Perhaps jemalloc could ignore the feature on that platform? Or make it an non-default feature in the crates.io code and turn it on for deployment?

EDIT: Oops, I didn't see this is already being resolved in #1956.

[jtgeibel]

Thanks @ehuss, that's alright. The biggest thing that surprised me is that jemalloc appears to behave very differently at runtime (ignoring the option on macOS) than with the same option compiled into the binary (always an error on macOS).