[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#45200: [PATCH] Force Glibc to free the memory freed
From: |
Konstantin Kharlamov |
Subject: |
bug#45200: [PATCH] Force Glibc to free the memory freed |
Date: |
Wed, 03 Feb 2021 11:23:43 +0300 |
User-agent: |
Evolution 3.38.3 |
On Wed, 2021-02-03 at 08:39 +0100, martin rudalics wrote:
> > Well, I didn't send the patches for my only benefit, but for benefit
> > of others people. The new ELisp function is something that not too
> > many people would benefit from, and I mean, including those who
> > disable GC.
>
> Does anyone really disable GC and get away with it?
Sure. There's for example this post¹, which is probably where I got the idea to
only run GC on idle from. The question is highly upvoted, it has 4k views, and
the only positive answer basically says "it's okay as long as you got memory"
(well, I got memory), and notes that there's also a point in only disabling GC
during startup. Similar advice to only disable it during startup has this
pretty upvoted reddit post²
Here's another example³, except in this case the author only disables GC while
they're inside minibuffer, and enables it back upon exiting. This then got
propogated here as well⁴
On top of that, there are countless advices on just increasing the
`gc-cons-threshold` (not inifitely increasing, just making some sane larger
value), that would surely reinforce an idea of just making GC run only on idle,
if one ever comes across such advice or just figures it out.
> > That is because it would be an opt-in feature, which you
> > need to know about to enable it, and not many will ever find out about
> > it.
>
> I wouldn't be afraid of that. In the past months we had a sufficient
> number of candidates caring about the memory consumption of their Emacs
> sessions. An opt-out feature OTOH would get us soon a couple of people
> who decide that your feature is responsible for some new slowness and
> recommend to throw it out. So making this an opt-in feature and at the
> same time giving some recommendations of what users can do when they
> detect that their sessions consumes more memory than expected would be a
> finely balanced solution IMO.
Well, I have 2 things to say on that.
First of, so far the impact seemed to be small. If one ever comes to blame the
new feature, they surely should have actual measurements to support that
hypothesis.
Second, most importantly, what `malloc_trim(0)` does is it restores the correct
behavior. I mean, what's the point of ever freeing memory if it's not freed,
right? The problem we're dealing here with is an actual bug in glibc⁵. What
this implies is that if the fix indeed hurts performance someplace, well, then
it's that this place requires additional performance-related fixes. As opposed
to just ignoring the bug because of performance got somewhere decreased. Things
like, changing the slow algorithm, or modifying GC behavior for specific
usecases…
It is the general rule that correct behavior rarely correlates with good
performance. You might for example omit locks in thread-heavy application, and
you get better performance at cost of thread races. Things like that.
---------
1:
https://emacs.stackexchange.com/questions/34342/is-there-any-downside-to-setting-gc-cons-threshold-very-high-and-collecting-ga
2:
https://www.reddit.com/r/emacs/comments/4j828f/til_setq_gcconsthreshold_100000000/d34gbsp/?context=3
3:
https://bling.github.io/blog/2016/01/18/why-are-you-changing-gc-cons-threshold/
4: https://javaguirre.me/2016/10/19/fixing-my-performance-problems-on-emacs
5: https://sourceware.org/bugzilla/show_bug.cgi?id=27103
- bug#45200: [PATCH] Force Glibc to free the memory freed, Konstantin Kharlamov, 2021/02/02
- bug#45200: [PATCH] Force Glibc to free the memory freed, Stefan Monnier, 2021/02/02
- bug#45200: [PATCH] Force Glibc to free the memory freed, Stefan Monnier, 2021/02/02
- bug#45200: [PATCH] Force Glibc to free the memory freed, martin rudalics, 2021/02/03
- bug#45200: [PATCH] Force Glibc to free the memory freed,
Konstantin Kharlamov <=
- bug#45200: [PATCH] Force Glibc to free the memory freed, martin rudalics, 2021/02/03
- bug#45200: [PATCH] Force Glibc to free the memory freed, Konstantin Kharlamov, 2021/02/03
- bug#45200: [PATCH] Force Glibc to free the memory freed, Konstantin Kharlamov, 2021/02/03
- bug#45200: [PATCH] Force Glibc to free the memory freed, martin rudalics, 2021/02/03
- bug#45200: [PATCH] Force Glibc to free the memory freed, Konstantin Kharlamov, 2021/02/03
- bug#45200: [PATCH] Force Glibc to free the memory freed, Konstantin Kharlamov, 2021/02/03
- bug#45200: [PATCH] Force Glibc to free the memory freed, martin rudalics, 2021/02/03
- bug#45200: [PATCH] Force Glibc to free the memory freed, Konstantin Kharlamov, 2021/02/03
- bug#45200: [PATCH] Force Glibc to free the memory freed, martin rudalics, 2021/02/03
- bug#45200: [PATCH] Force Glibc to free the memory freed, Stefan Monnier, 2021/02/03