Closed Bug 1277704 Opened 3 years ago Closed 3 years ago

Update jemalloc 4 to version 4.3.1

Categories

(Core :: Memory Allocator, defect, P1)

defect

Tracking

()

RESOLVED FIXED
mozilla52
Tracking Status
firefox52 --- fixed

People

(Reporter: RyanVM, Assigned: RyanVM)

References

Details

Attachments

(1 file, 3 obsolete files)

* 4.2.0 (May 12, 2016)

New features:
  - Add the arena.<i>.reset mallctl, which makes it possible to discard all of
    an arena's allocations in a single operation.  (@jasone@)
  - Add the stats.retained and stats.arenas.<i>.retained statistics.  (@jasone)
  - Add the --with-version configure option.  (@jasone)
  - Support --with-lg-page values larger than actual page size.  (@jasone)

Optimizations:
  - Use pairing heaps rather than red-black trees for various hot data
    structures.  (@djwatson, @jasone)
  - Streamline fast paths of rtree operations.  (@jasone)
  - Optimize the fast paths of calloc() and [m,d,sd]allocx().  (@jasone)
  - Decommit unused virtual memory if the OS does not overcommit.  (@jasone)
  - Specify MAP_NORESERVE on Linux if [heuristic] overcommit is active, in order
    to avoid unfortunate interactions during fork(2).  (@jasone)

Bug fixes:
  - Fix chunk accounting related to triggering gdump profiles.  (@jasone)
  - Link against librt for clock_gettime(2) if glibc < 2.17.  (@jasone)
  - Scale leak report summary according to sampling probability. (@jasone)
Attachment #8759399 - Flags: review?(mh+mozilla)
Attachment #8759399 - Flags: review?(mh+mozilla) → review+
Can you do a try push with tests with jemalloc4 enabled?
Looks like there's win32 xpcshell crashes during startup cache precompilation :(
https://treeherder.mozilla.org/logviewer.html#?job_id=21907507&repo=try

Win64 builds are fine (which explains why I haven't encountered issues testing locally).
4.2.1 was released with what could possibly be a fix to those issues. Please try it.
Things with 4.2.1 look mostly fine now, except Win64 jittests became nearly perma-timeout. An m-c Try push w/ 4.1.1 doesn't show any issues like that.

4.1.1: https://treeherder.mozilla.org/#/jobs?repo=try&revision=c7269ed22ee1&filter-searchStr=win%20x64%20opt%20jit

4.2.1: https://treeherder.mozilla.org/#/jobs?repo=try&revision=87a7154378c3&filter-searchStr=win%20x64%20opt%20jit

The initial Win64 build also hit an xpcshell selftest failure I've never seen before, but a retrigger came back green. Can't say with any certainty that it's related to jemalloc, though.
https://treeherder.mozilla.org/logviewer.html#?job_id=22266484&repo=try
Summary: Update jemalloc 4 to version 4.2.0 → Update jemalloc 4 to version 4.2.1
Attachment #8759399 - Attachment is obsolete: true
I triggered more Win8 jittest runs on the 4.2.0 Try push and there weren't any issues either.
Priority: -- → P1
Duplicate of this bug: 1295985
One of the recent commits to the rel-4.3.0 branch appears to have made Win64 jittests a lot happier (that or something on our end is playing more nicely with jemalloc). So that's encouraging.
https://treeherder.mozilla.org/#/jobs?repo=try&revision=5f6715fd037c9600c4d2ba75464c560869d73f9a
Summary: Update jemalloc 4 to version 4.2.1 → Update jemalloc 4 to version 4.3.0
4.3.0 is out now. Changelogs since comment 0:

* 4.2.1 (June 8, 2016)

Bug fixes:
  - Fix bootstrapping issues for configurations that require allocation during tsd initialization (e.g. --disable-tls). (@cferris1000, @jasone)
  - Fix gettimeofday() version of nstime_update(). (@ronawho)
  - Fix Valgrind regressions in calloc() and chunk_alloc_wrapper(). (@ronawho)
  - Fix potential VM map fragmentation regression. (@jasone)
  - Fix opt_zero-triggered in-place huge reallocation zeroing. (@jasone)
  - Fix heap profiling context leaks in reallocation edge cases. (@jasone)

* 4.3.0 (November 4, 2016)

New features:

  - Add "J" (JSON) support to malloc_stats_print(). (@jasone)
  - Add Cray compiler support. (@ronawho)

Optimizations:

  - Add/use adaptive spinning for bootstrapping and radix tree node initialization. (@jasone)

Bug fixes:

  - Fix large allocation to search starting in the optimal size class heap, which can substantially reduce virtual memory churn and fragmentation. This regression was first released in 4.0.0. (@mjp41, @jasone)
  - Fix stats.arenas.<i>.nthreads accounting. (@interwq)
  - Fix and simplify decay-based purging. (@jasone)
  - Make DSS (sbrk(2)-related) operations lockless, which resolves potential deadlocks during thread exit. (@jasone)
  - Fix over-sized allocation of radix tree leaf nodes. (@mjp41, @ogaun, @jasone)
  - Fix over-sized allocation of arena_t (plus associated stats) data structures. (@jasone, @interwq)
  - Fix EXTRA_CFLAGS to not affect configuration. (@jasone)
  - Fix a Valgrind integration bug. (@ronawho)
  - Disallow 0x5a junk filling when running in Valgrind. (@jasone)
  - Fix a file descriptor leak on Linux. This regression was first released in 4.2.0. (@vsarunas, @jasone)
  - Fix static linking of jemalloc with glibc. (@djwatson)
  - Use syscall(2) rather than {open,read,close}(2) during boot on Linux. This works around other libraries' system call wrappers performing reentrant allocation. (@kspinka, @Whissi, @jasone)
  - Fix OS X default zone replacement to work with OS X 10.12. (@glandium, @jasone)
  - Fix cached memory management to avoid needless commit/decommit operations during purging, which resolves permanent virtual memory map fragmentation issues on Windows. (@mjp41, @jasone)
  - Fix TSD fetches to avoid (recursive) allocation. This is relevant to non-TLS and Windows configurations. (@jasone)
  - Fix malloc_conf overriding to work on Windows. (@jasone)
  - Forcibly disable lazy-lock on Windows (was forcibly enabled). (@jasone)
With bug 1293501 backed out, this looks good on Try.
https://treeherder.mozilla.org/#/jobs?repo=try&revision=d37f32acf9e72eb21fe6828d3259c19e490d535d

And just for fun, here's a Perfherder comparison of jemalloc4 enabled vs. disabled these days.
https://treeherder.mozilla.org/perf.html#/compare?originalProject=try&originalRevision=c305e32e95f5&newProject=try&newRevision=ec3541f12129&framework=1&showOnlyImportant=0

Hannes, can you please run an AWFY comparison of Try rev c305e32e95f5 and rev ec3541f12129 per our IRC chat?

Eric, can we run this through AWSY as well?
Attachment #8762021 - Attachment is obsolete: true
Flags: needinfo?(hv1989)
Flags: needinfo?(erahm)
Attachment #8807849 - Flags: review?(mh+mozilla)
We should wait for jemalloc 4.3.1, which will fix some regressions in 4.3.0: 

https://github.com/jemalloc/jemalloc/issues/496
* 4.3.1 (November 7, 2016)

Bug fixes:
  - Fix a severe virtual memory leak.  This regression was first released in
    4.3.0.  (@interwq, @jasone)
  - Refactor atomic and prng APIs to restore support for 32-bit platforms that
    use pre-C11 toolchains, e.g. FreeBSD's mips.  (@jasone)
Summary: Update jemalloc 4 to version 4.3.0 → Update jemalloc 4 to version 4.3.1
(In reply to Ryan VanderMeulen [:RyanVM] from comment #16)
> Created attachment 8808443 [details] [diff] [review]
> update jemalloc 4 to version 4.3.1
> 
> Try push:
> https://treeherder.mozilla.org/#/
> jobs?repo=try&revision=99fab19cf0d3c3754636c3b9fa4884e2291438cf&group_state=e
> xpanded
> 
> Push w/o jemalloc 4 enabled for perf comparisons:
> https://treeherder.mozilla.org/#/
> jobs?repo=try&revision=e29a6b16a9c90fce4d3c59a974dbc4d735848727
> 
> Perfherder comparison:
> https://treeherder.mozilla.org/perf.html#/
> compare?originalProject=try&originalRevision=e29a6b16a9c90fce4d3c59a974dbc4d7
> 35848727&newProject=try&newRevision=99fab19cf0d3c3754636c3b9fa4884e2291438cf&
> framework=1&showOnlyImportant=0

Oh my... can you push another one with the in-tree jemalloc 4.x to compare 4.3.1 against it?
Attachment #8808443 - Flags: review?(mh+mozilla) → review+
Pushed by ryanvm@gmail.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/c6d5c06685a2
Update jemalloc 4 to version 4.3.1. r=glandium
https://hg.mozilla.org/mozilla-central/rev/c6d5c06685a2
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla52
(In reply to Ryan VanderMeulen [:RyanVM] from comment #13)
> Hannes, can you please run an AWFY comparison of Try rev c305e32e95f5 and
> rev ec3541f12129 per our IRC chat?

Sorry about the delay. If I didn't scripted something wrong the following should give results in a couple of hours:
https://arewefastyet.com/task_info.php?id=44990
https://arewefastyet.com/task_info.php?id=44991
https://arewefastyet.com/task_info.php?id=44992
https://arewefastyet.com/task_info.php?id=44993
https://arewefastyet.com/task_info.php?id=44994
https://arewefastyet.com/task_info.php?id=44995

You'll have to scroll to the bottom to get a json list of all results upon completion.
I've scheduled both revisions 3 times.
Flags: needinfo?(hv1989)
(In reply to Ryan VanderMeulen [:RyanVM] from comment #13)
> Created attachment 8807849 [details] [diff] [review]
> update jemalloc 4 to version 4.3.0
> 
> With bug 1293501 backed out, this looks good on Try.
> https://treeherder.mozilla.org/#/
> jobs?repo=try&revision=d37f32acf9e72eb21fe6828d3259c19e490d535d
> 
> And just for fun, here's a Perfherder comparison of jemalloc4 enabled vs.
> disabled these days.
> https://treeherder.mozilla.org/perf.html#/
> compare?originalProject=try&originalRevision=c305e32e95f5&newProject=try&newR
> evision=ec3541f12129&framework=1&showOnlyImportant=0
> 
> Hannes, can you please run an AWFY comparison of Try rev c305e32e95f5 and
> rev ec3541f12129 per our IRC chat?
> 
> Eric, can we run this through AWSY as well?

Sorry late reply, we now have awsy in-tree. Just add -u awsy-e10s to your push and you'll be able to do perfherder comparison for the 'sy' job. Similar to talos retrigger generously.
Flags: needinfo?(erahm)
You need to log in before you can comment on or make changes to this bug.