Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Software memory management reengineering

Reply
Thread Tools

Software memory management reengineering

 
 
jacob navia
Guest
Posts: n/a
 
      10-13-2007
Ian Collins wrote:
> jacob navia wrote:
>> Richard Heathfield wrote:
>>
>>> The point is that you have to think about this stuff up front.

>> This is wrong.
>>
>> There is absolutely no need to over engineer a program, making it manage
>> memory up front. You allocate memory without freeing it. If this ever
>> becomes a problem you add a pool based strategy or a garbage collector.
>>

> I can see you have never worked on embedded systems.
>


I am speaking of transient programs, i.e. programs that do
something, then exit. Embedded systems do have transient programs
if they have an OS. Otherwise they don't.

>> Utilities that produce directory listings, linkers, compilers, filters,
>> text searching tools, there are many examples of transient programs.
>> In many of them, ignoring memory allocation problems makes them faster,
>> leaner, and less error prone, since all the bugs associated with
>> "free()" calls can be avoided.
>>

> You fail to realise that your leaky directory listing routine may get
> invoked recursively in something like a backup utility, or get called
> hundreds or even thousands of times in a test suite.
>


A transient program, as I have explained several times already, leaves
its cleanup to the operating system. Thus, it can be called thousands
of times, it will always cleanup implicitly.

I can repeat this again and again and apparently there will be always
the same "argument"...

Even in a recursive call if you call my program with some way like
system("dodir"); or whatever, it will always cleanup! And this will not
change even if it is called hundred billion times!


--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
 
Reply With Quote
 
 
 
 
Richard Heathfield
Guest
Posts: n/a
 
      10-13-2007
jacob navia said:

> Richard Heathfield wrote:
>> Ben Pfaff said:
>>

> [snip]
>>> ... at what point does pool-based allocation descend to that
>>> level?

>>
>> At the point where you try to retrofit it into a program (such as I
>> described upthread) that was written without pool-based allocation in
>> mind, in the hope of magically fixing the failure to deal with memory
>> housekeeping properly. If pool-based allocation is part of a sensible,
>> coherent design strategy that is part of the original program design,
>> that's obviously a very different matter.
>>

> This is wrong.


No, it isn't. You need to learn to tell right from wrong. For the past few
years, you appear to have got them mixed up with monotonous regularity.

>
> In a pool managed memory allocation strategy you make a lot of
> allocations that go into the same pool, then release the pool.


Fine, provided there's enough memory, which - in the example I gave - there
wasn't.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
 
Reply With Quote
 
 
 
 
Richard Heathfield
Guest
Posts: n/a
 
      10-13-2007
jacob navia said:

<snip>

> A transient program, as I have explained several times already, leaves
> its cleanup to the operating system. Thus, it can be called thousands
> of times, it will always cleanup implicitly.


I have already given an example, upthread, of what you call a "transient"
program which became a "non-transient" program five years later. Skimp on
the housekeeping now, and pay for it many times over in the future.

> I can repeat this again and again and apparently there will be always
> the same "argument"...


No matter how many times you repeat an incorrect argument, it remains
incorrect.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      10-13-2007
jacob navia wrote:
> Ian Collins wrote:
>> jacob navia wrote:
>>> Richard Heathfield wrote:
>>>
>>>> The point is that you have to think about this stuff up front.
>>> This is wrong.
>>>
>>> There is absolutely no need to over engineer a program, making it manage
>>> memory up front. You allocate memory without freeing it. If this ever
>>> becomes a problem you add a pool based strategy or a garbage collector.
>>>

>> I can see you have never worked on embedded systems.
>>

>
> I am speaking of transient programs, i.e. programs that do
> something, then exit. Embedded systems do have transient programs
> if they have an OS. Otherwise they don't.
>

"Transient programs" contain components. Those components, if they are
any use, will get reused. Unless you stick a great big fluorescent
label on them "Danger, the authour was too slack to free memory" the
component may be reused in something other than a "transient programs".

>> You fail to realise that your leaky directory listing routine may get
>> invoked recursively in something like a backup utility, or get called
>> hundreds or even thousands of times in a test suite.

>
> A transient program, as I have explained several times already, leaves
> its cleanup to the operating system. Thus, it can be called thousands
> of times, it will always cleanup implicitly.
>

I wasn't talking about the program, I was talking about the leaky
routine that reads a directory. Or do you write all of you code in main?

--
Ian Collins.
 
Reply With Quote
 
jacob navia
Guest
Posts: n/a
 
      10-13-2007
Ian Collins wrote:
> I wasn't talking about the program, I was talking about the leaky
> routine that reads a directory. Or do you write all of you code in main?
>


This is the problem. I am always talking about transient
*program* and you are talking about some routine!

I repeat:

Lazy allocation can be done only at the program level. I have
always maintained this.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      10-13-2007
jacob navia wrote:
> Ian Collins wrote:
>> I wasn't talking about the program, I was talking about the leaky
>> routine that reads a directory. Or do you write all of you code in main?
>>

>
> This is the problem. I am always talking about transient
> *program* and you are talking about some routine!
>
> I repeat:
>
> Lazy allocation can be done only at the program level. I have
> always maintained this.
>

But what is is program if it isn't a collection of routines?

--
Ian Collins.
 
Reply With Quote
 
jacob navia
Guest
Posts: n/a
 
      10-13-2007
Ian Collins wrote:
> jacob navia wrote:
>> I repeat:
>>
>> Lazy allocation can be done only at the program level. I have
>> always maintained this.
>>

> But what is is program if it isn't a collection of routines?
>


Maybe you haven't noticed it yet, but after a program finishes the
operating system cleans up. Not so for a routine.

And you know what?

"There is no blinder person as the one that doesn't want to see".


--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      10-13-2007
jacob navia wrote:
> Ian Collins wrote:
>> jacob navia wrote:
>>> I repeat:
>>>
>>> Lazy allocation can be done only at the program level. I have
>>> always maintained this.
>>>

>> But what is is program if it isn't a collection of routines?
>>

>
> Maybe you haven't noticed it yet, but after a program finishes the
> operating system cleans up. Not so for a routine.
>

So? Enough of this, I'm off to find an open pub and celebrate England's
victory over France in the wold cup....

--
Ian Collins.
 
Reply With Quote
 
rosewater@mailinator.com
Guest
Posts: n/a
 
      10-13-2007
jacob navia wrote:
> And you know what?
>
> "There is no blinder person as the one that doesn't want to see".


Said without the slightest trace of irony...

 
Reply With Quote
 
Willem
Guest
Posts: n/a
 
      10-13-2007
jacob wrote:
) This is the problem. I am always talking about transient
) *program* and you are talking about some routine!
)
) I repeat:
)
) Lazy allocation can be done only at the program level. I have
) always maintained this.

Maybe I should butt in and also repeat:

Programs often get reused and turned (partly) into routines.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
reengineering c++ code that uses pthreads on Sun Solaris My Python C++ 7 06-03-2011 01:39 AM
Project management / bug management Floris van Haaster ASP .Net 3 09-23-2005 08:36 PM
CatOS web management or CiscoView management ? Martin Bilgrav Cisco 1 12-20-2003 01:49 PM
perl memory management - does @array = () free the memory? Matt Oefinger Perl Misc 0 06-25-2003 09:11 PM



Advertisments