Object/variable scope problems (Linux and Win comparison)

[Goran]

Le 28/02/11 16:46, Leigh Johnston a crit :






There are several memory management and memory use strategies. I have
enumerated the most used ones in my tutorial (about the C language,
not the C++ language) available here:

http://www.cs.virginia.edu/~lcc-win32/

Some of the principles there apply here, specifically the 'Never free()'
strategy.

This strategy avoids all problems associated with free() (in C++
"delete") by never freeing or deleting any memory and allowing the
OS to clean up everything much more efficiently.

This strategy is indicated for transient programs, that allocate a
lot of memory, and almost never release anything until they exit.

Yes, but this fails when:

* code is run on an OS where closing a process does not free said
memory (yes, that exists, and you seem to presume it does not)
* total heap needed surpasses total heap available, but peak heap does
not; that can happen e.g. when
** code is changed
** data set got bigger
** code is run in an environment where available heap is reduced by
administrative means
* objects not deleted hold otherwise scarce resources (e.g. DB
connection etc handles). By the way, are you sure that OS cleans up
such resources? I sure am not, OS knows nothing of such things
* code is taken out to be used in a different context (e.g. something
long-running)

It's bad advice, __especially__ when given to students (your link is
coming from an "edu" domain). It's exactly cowboy style, as evoked:
play fast and loose, damn the consequences. No thanks. How about at
least starting and ending the lecture on this strategy with "don't do
this at home"?

Goran.

 

[Miles Bader]

Yes, but this fails when:

* code is run on an OS where closing a process does not free said
memory (yes, that exists, and you seem to presume it does not)
* total heap needed surpasses total heap available, but peak heap does
not; that can happen e.g. when
** code is changed
** data set got bigger
** code is run in an environment where available heap is reduced by
administrative means
* objects not deleted hold otherwise scarce resources (e.g. DB
connection etc handles). By the way, are you sure that OS cleans up
such resources? I sure am not, OS knows nothing of such things
* code is taken out to be used in a different context (e.g. something
long-running)

Another issue is debugging -- one very good way to identify memory leaks
is to use a tool like valgrind, but the presence of "harmless"
intentional leaks make this more difficult.

-Miles

 

[marusja marusjake]

Another issue is debugging -- one very good way to identify memory leaks
is to use a tool like valgrind, but the presence of "harmless"
intentional leaks make this more difficult.

I have also used to leak absolutely everything for performance reasons
of a little program. The code however leaked nothing in debug version.
The whole trick was to make free()/operator delete() to do nothing in
release version to gain such effect.

 

[Miles Bader]

I have also used to leak absolutely everything for performance reasons
of a little program. The code however leaked nothing in debug version.
The whole trick was to make free()/operator delete() to do nothing in
release version to gain such effect.

Sure, one can do that, and if it's OK to make _every_ allocation leak,
then it might even be really easy...

In a more typical program, where one can't just leak everything, another
way to gain performance by intentional "leaking" of certain allocations
is to make those allocations from a special arena that's later freed in
bulk at appropriate times. So the memory _is_ eventually freed, just
not using the same granularity as the allocations. [And allocations can
be much faster too, e.g. just an inlined bounds-check and
pointer-increment.]

-Miles

 

[jacob navia]

Le 04/03/11 04:44, Miles Bader a écrit :

I have also used to leak absolutely everything for performance reasons
of a little program. The code however leaked nothing in debug version.
The whole trick was to make free()/operator delete() to do nothing in
release version to gain such effect.

Sure, one can do that, and if it's OK to make _every_ allocation leak,
then it might even be really easy...

In a more typical program, where one can't just leak everything, another
way to gain performance by intentional "leaking" of certain allocations
is to make those allocations from a special arena that's later freed in
bulk at appropriate times. So the memory _is_ eventually freed, just
not using the same granularity as the allocations. [And allocations can
be much faster too, e.g. just an inlined bounds-check and
pointer-increment.]

-Miles

Yes, you have rediscovered pool managed memory allocation strategy. In
the tutorial I mentioned I described that strategy, and why it is easy
to pass from my "never free" strategy to a pool managed strategy.

Suppose that you got a program written in the (much criticized)
"leaking" strategy. You absolutely do NOT want to have leaks in your
program.

Thye solution is to allocate a pool for the concerned software,
and after it is finished to free the allocated pool in a single
call to free().

This remains efficient but it is compatible with a non-transient
program.

Other ways of "upgrading" a leaking program without fixing all
leaks is the garbage collector. Boehm has provided one for C
and C++. I understand that in C++ is more difficult to integrate it
but it can be really useful in plain C.

 

[itaj sherman]

Le 04/03/11 04:44, Miles Bader a crit :

In a more typical program, where one can't just leak everything, another
way to gain performance by intentional "leaking" of certain allocations
is to make those allocations from a special arena that's later freed in
bulk at appropriate times.  So the memory _is_ eventually freed, just
not using the same granularity as the allocations.  [And allocations can
be much faster too, e.g. just an inlined bounds-check and
pointer-increment.]

Yes, you have rediscovered pool managed memory allocation strategy. In
the tutorial I mentioned I described that strategy, and why it is easy
to pass from my "never free" strategy to a pool managed strategy.

He actually gives that more careful explanation, as you go on doing
now, but didn't before.
Saying only "it's ok to skip deallocation" to a c++ student is
dangerous, even more so as you said "skip delete".

itaj

 

[jacob navia]

Le 04/03/11 15:08, itaj sherman a écrit :

Saying only "it's ok to skip deallocation" to a c++ student is
dangerous, even more so as you said "skip delete".

itaj

Yes, you are right. I should have qualified better my statement.