Valgrind is no longer supported in 5.0 but no reason was provided

[thedrow]

Does this mean we cannot debug memory leaks with Valgrind anymore? Is the support no longer needed and Valgrind just works?
What are the implications here? They should be described in the release notes if possible.

[interwq]

Please see the discussion in #369.

[thedrow]

At the very least, the release notes should include a reference to that issue.
This has serious implications towards ease of development with jemalloc.
Essentially you guys are saying that it is no longer possible to detect memory leaks with jemalloc easily which will be a blocker for a lot of projects. Especially large projects that utilize jemalloc's API instead of just using a better malloc.

[jasone]

@thedrow, we make no such claim regarding lack of memory leak diagnostics capabilities. In fact, the statistical heap profiling functionality that has been part of jemalloc since 1.0.0 tends to be more versatile than Valgrind for the purposes of leak detection and diagnosis, because it imposes little enough overhead to be usable in all but the most performance-sensitive use cases.

Regarding the ChangeLog, our goal is to succinctly enumerate all the changes that have potential relevance to people as they adopt new versions, as an aid in deciding what needs further investigation. The ChangeLog is not intended as a detailed rationale for the entire commit history. The full git history is available for your perusal, and you can look at the 5.0.0 milestone issues for a different perspective.

Stepping back, I get the sense you're really upset about the feature removal, rather than how its removal was documented. We had Valgrind integration support for all of the 3.x and 4.x releases, but the feature imposed substantial internal complexity (redzones and quarantine), and regressions often went unreported for multiple releases, especially once my colleagues at Facebook shifted their memory correctness testing from Valgrind to ASan. The integration was notoriously easy to subtly break, and we had no Valgrind-specific regression tests. When I considered how poorly we were maintaining Valgrind integration, in combination with its reduced role relative to ASan, and the desire to add features like arena reset/destroy that Valgrind integration would have made much more difficult, the choice was clear. If there were active jemalloc developers who cared about maintaining high quality Valgrind integration, we might instead have chosen to improve our test coverage, but we didn't even have consistent regression reporting, let alone active interest. Given a choice of complaints due to feature removal, and the dissatisfaction of shipping faulty code for a diminishing use case, I choose the former.