Heavy malloc()/free() load and threads
in [Unix Programming]
|
From: Ersek, Laszlo on 13 Mar 2010 13:54 In article <87hbomyl0w.fsf(a)fever.mssgmbh.com>, Rainer Weikusat <rweikusat(a)mssgmbh.com> writes: > The only real-world benefit of > 'malloc' is that it enables someone using it to avoid writing 50 - 300 > LOC, based on the complexity of the allocation requirements. Do those 50-300 lines of code manipulate blocks returned by initial malloc()'s? If not, how portable are such hand-written allocators, compared to malloc()? Thanks, lacos
From: David Given on 14 Mar 2010 09:16 On 11/03/10 16:12, Måns Rullgård wrote: [...] > Almost all cases are specific. That said, one should only use custom > memory management after the default malloc has been shown to be a problem. I used to work for an embedded systems company that produced an OS that could run either bare-metal or hosted on top of another OS. When running hosted, we had a memory allocator that just mapped directly onto the host malloc()/free() functions. Much to our surprise, we discovered that most embedded malloc()/free() operations are horrifically slow. We ended up switching to using our own memory allocator that managed chunks of memory claimed from the host OS; despite the extra overhead, this was much, much faster (and frequently less buggy). So, YMMV. -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ───── │ │ life←{ ↑1 ⍵∨.^3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵ } │ --- Conway's Game Of Life, in one line of APL
From: Rainer Weikusat on 14 Mar 2010 16:40 lacos(a)ludens.elte.hu (Ersek, Laszlo) writes: > In article <ygfzl2fxh5k.fsf(a)janus.isnogud.escape.de>, Urs Thuermann <urs(a)isnogud.escape.de> writes: > >> 1. Will typical implementations of malloc()/free() in libc handle this >> load well? Or should I implement my own memory management? > > If you intend to use valgrind, the following link may be pertinent: > > http://valgrind.org/docs/manual/manual-core.html#manual-core.limits > > ----v---- > If your program does its own memory management, rather than using > malloc/new/free/delete, it should still work, but Memcheck's error > checking won't be so effective. If you describe your program's memory > management scheme using "client requests" (see The Client Request > mechanism), Memcheck can do better. Nevertheless, using malloc/new and > free/delete is still the best approach. > ----^---- > > (This is no advice, just a bit of trivia so you can make a more informed > decision, in either way.) Realistically, memory leaks are especially common in code which lacks any kind of memory managment, IOW, just uses malloc/ free naively.
From: Eric Sosman on 14 Mar 2010 16:46 On 3/14/2010 4:40 PM, Rainer Weikusat wrote: > > Realistically, memory leaks are especially common in code which lacks > any kind of memory managment, IOW, just uses malloc/ free naively. Realistically, this is nonsense. -- Eric Sosman esosman(a)ieee-dot-org.invalid
From: Rainer Weikusat on 14 Mar 2010 17:41
Eric Sosman <esosman(a)ieee-dot-org.invalid> writes: > On 3/14/2010 4:40 PM, Rainer Weikusat wrote: >> >> Realistically, memory leaks are especially common in code which lacks >> any kind of memory managment, IOW, just uses malloc/ free naively. > > Realistically, this is nonsense. Your experiences may be different from mine. This would then mean that either you know of something I don't know about or I know of something you don't know about, with probability of the former being significantly higher than the probability of the latter. There are, however, three reasons why I consider mine to be 'sufficiently representative': - A memory leak occurs whenever space allocated in order to accomplish a particular task isn't 'freed' before the pointer pointing to it is gone. Usually, this is an oversight on part of the person who wrote the code. The chances that a human forgets something increases with the number of different somethings which must be remembered. Code which has been written with an 'just call malloc whenever you need a buffer'-attitude will contain lots of malloc calls and this means there are a lot of opportunities to forget to also call free. - Usually, people who are having problems they cannot deal with anymore manually tend to rather write tools to help them with being able to continue to act in problem-creating ways than to consider changing their habits. Valgrind is such a tool and it has excellent support for 'straight' malloc/free and basically no support for anything else. - Custom allocators (eg as in, Apache2, Postgres or Samba) are often specifically designed to enable easy 'freeing' of memory which is no longer in use. Two common solutions suggest that a problem actually exists. |