Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The effect of switching to TCMalloc on RocksDB memory use

blog.cloudflare.com

Post reply on HN
Print view View original

41–49 of 49 posts

Re: The effect of switching to TCMalloc on RocksDB memory use

#41

Post by benlivengood »

Another option is explicit memory pools when some classes of allocation have well-defined lifetimes. Freeing an entire pool is instant compared to either free()/delete or GC and produces zero fragmentation.

For example, build parse trees in explicit pools and deallocate the whole tree and associated allocations when done with it.

Language support for this is fairly poor or tricky in OO languages AFAIK; but I'm mostly familiar with C++ where destructors and lack of allocator scoping (until C++11, but optional) make this a pain. The language needs support for formally and transitively abandoning objects (or not caring, like C) to support efficient use of memory pools.

Re: The effect of switching to TCMalloc on RocksDB memory use

#42

Post by nateberkopec »

volgar1x wrote: post #28
nateberkopec wrote: post #14

This problem hit the Ruby community hard about 5 years ago. Basically everyone uses jemalloc or tcmalloc in production in the Ruby community nowadays. What frustrates me is the malloc community's sort of blase reaction along the lines of "there's no bug, this is expected behavior".

Why try to optimize for every cases possible ? Use the right tool for the right job.

"multihreaded programs" seems like a pretty big use case, and it seems to occur in just about every major multithreaded C program using glibc malloc.

I would agree with you if it didn't seem like other allocators are solving this without any tradeoffs.

Re: The effect of switching to TCMalloc on RocksDB memory use

#43

Post by fvv »

Lol 15years ago I fixed the same problem in some long running memory hungry multithreaded c++ application in same way .. and i was wondering why such hack was necessary and not default.. i remember reading some guide in some Google blog which was already dated by then... 15 years and not yet fixed(defaulted) ? Btw I'm not using c++ anymore

Re: The effect of switching to TCMalloc on RocksDB memory use

#44

Post by fvv »

fvv wrote: post #43

Lol 15years ago I fixed the same problem in some long running memory hungry multithreaded c++ application in same way .. and i was wondering why such hack was necessary and not default.. i remember reading some guide in some Google blog which was already dated by then... 15 years and not yet fixed(defaulted) ? Btw I'm not using c++ anymore

Maybe was this http://goog-perftools.sourceforge.net/doc/tcmalloc.html

Re: The effect of switching to TCMalloc on RocksDB memory use

#45

Post by tssva »

dragontamer wrote: post #37
jerf wrote: post #30

Earlier quoted context omitted.

This sort of thing is why I'm generally not impressed by the perennial "GC vs. manual memory management" debate. Manual memory management usually isn't. Simply using "malloc" isn't manual memory management, there's still a lot of stuff going on behind the scenes that may or may not match your program's use case. Both GC and "manual" memory management aren't single points, they're suites of options, which you can ofte…

> "Pie tastes better than cake!" Indeed. And is Cheesecake a pie or a cake? You bake cheesecake in pie-crust, but it has cake in the name. The memory-management "its both" scheme is reference-counting. In some contexts, its ref-counts are considered manual (C++ shared_ptr, Rust). In other contexts, its considered automated garbage collection (Python, Lisp). In all cases: tons of atomic add/subtract + memory-barriers…

"And is Cheesecake a pie or a cake? You bake cheesecake in pie-crust, but it has cake in the name."

I tried to follow the rest of your comment but I was too disturbed by you thinking all cheesecake is baked in pie-crust.

Re: The effect of switching to TCMalloc on RocksDB memory use

#46

Post by dragontamer »

tssva wrote: post #45
dragontamer wrote: post #37

Earlier quoted context omitted.

> "Pie tastes better than cake!" Indeed. And is Cheesecake a pie or a cake? You bake cheesecake in pie-crust, but it has cake in the name. The memory-management "its both" scheme is reference-counting. In some contexts, its ref-counts are considered manual (C++ shared_ptr, Rust). In other contexts, its considered automated garbage collection (Python, Lisp). In all cases: tons of atomic add/subtract + memory-barriers…

"And is Cheesecake a pie or a cake? You bake cheesecake in pie-crust, but it has cake in the name." I tried to follow the rest of your comment but I was too disturbed by you thinking all cheesecake is baked in pie-crust.

https://www.target.com/p/keebler-graham-cracker-pie-crust-9-...

There's literally a cheesecake on the "serving suggestion" image for the pie crust. I can't be the only one who makes cheesecakes on these...

Re: The effect of switching to TCMalloc on RocksDB memory use

#47

Post by api »

alexhutcheson wrote: post #23
api wrote: post #6

Why don’t things like malloc get fixed? I’ve known about these issues for years. Does the core team not know?

The FSF requires copyright assignment for code added to glibc, which makes it difficult to add code from other projects.

What if you asked those other projects? I find it tough to believe nobody would contribute. It’s not like the other mallocs are for profit products.

Re: The effect of switching to TCMalloc on RocksDB memory use

#48

Post by alexhutcheson »

api wrote: post #47
alexhutcheson wrote: post #23

Earlier quoted context omitted.

The FSF requires copyright assignment for code added to glibc, which makes it difficult to add code from other projects.

What if you asked those other projects? I find it tough to believe nobody would contribute. It’s not like the other mallocs are for profit products.

Unless those projects have required copyright assignments (neither does, to my knowledge), then you’d need to get agreement from the copyright holder for every contribution that still has code in the project. If there are any holdouts (or even any people you just couldn’t get in touch with) then you’d need to remove the parts they contributed to proceed.

More practically, anyone who was asked could reasonably respond “Why do you need to own the copyright? It’s already permissively licensed (in jemalloc’s case, with an LGPLv2.1-compatible license) - just use it!” FSF policy is the only obstacle, and they could make an exception if they wanted to.

Re: The effect of switching to TCMalloc on RocksDB memory use

#49

Post by tssva »

dragontamer wrote: post #46
tssva wrote: post #45

Earlier quoted context omitted.

"And is Cheesecake a pie or a cake? You bake cheesecake in pie-crust, but it has cake in the name." I tried to follow the rest of your comment but I was too disturbed by you thinking all cheesecake is baked in pie-crust.

https://www.target.com/p/keebler-graham-cracker-pie-crust-9-... There's literally a cheesecake on the "serving suggestion" image for the pie crust. I can't be the only one who makes cheesecakes on these...

The keyword in my comment was "all". There are types of cheesecake baked in pie crust but it is far from all cheesecakes. Certainly far enough from far to be posing the original question.
Post reply on HN