Garbage collection: Memory leak?

Question

Let's roll:

$ emacs -Q
M-x shell
$ while true; do echo XXXXXXXX; done

Depending on how much RAM you have in total, wait for some reasonable amount. For instance, I'm typically waiting until the shell buffer is around 5M lines and the corresponding memory consumption is around 5G.

It is indeed clear why it grows. However, when I kill the buffer, the amount of memory occupied by Emacs is still 5G. I'm aware of garbage collection (GC) and two variables gc-cons-threshold and gc-cons-percentage, for which I tried different values without luck (including default). Waiting for some time does not seem to somehow lazily trigger any GC process either. Finally, even directly issuing

M-x garbage-collect

has no effect at all; the amount of occupied memory by Emacs remains at 5G and Emacs does not freeze even for a second to perform GC (which should definitely happen for such a large amount of memory).

Does anybody experience the same issue? I observe this on both 24 and 25 series. The reason why this issue has become really annoying lately is because I have to run many buffers tailing various continuously written logs, but killing any of these buffers does not seem to release the memory back. As a result, I simply run out of memory hourly, what forces me to quit Emacs and restart it to be able to continue work. What to do?

NOTE:
Of course,

(setq-default garbage-collection-messages t)

does show the "Garbage collecting...done" messages in minibuffer continuously, what means that GC is indeed performed but, in fact, that confuses me even more. Why the memory is not released when the buffer is killed?

Answer 1

Thanks to @npostavs, I decided to rebuild Emacs from master. That is

GNU Emacs 26.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.15) of 2017-06-10

configured with

Should Emacs use the GNU version of malloc?             no (only before dumping)
Should Emacs use a relocating allocator for buffers?    no
Should Emacs use mmap(2) for buffer allocation?         no

now starts fresh with 120M. Then following my original question, I can even go up to 10M lines and surprisingly the memory consumption is only up to 360M. If I then kill that buffer, within the next GC, it's going down to 220M, and within one more, it's going down to 160M and stays there regardless of further GC attempts.

This is certainly a huge improvement! Clearly, Emacs developers fixed some serious allocation/deallocation issues in the 26 series. GJ! Though it is still unclear why it does not get back to the starting 120M, but I guess I should not worry much about this as this might be as well an optimization (something like a prediction by allocator not to give up all of what it has had as more memory is likely to be needed again soon).