In article <5pCdnWbp1rsoKaLeRVnyuw@pipex.net>, Steve at fivetrees <steve@NOSPAMTAfivetrees.com> wrote:>"Nick Maclaren" <nmm1@cus.cam.ac.uk> wrote in message >news:dhobjl$e2v$1@gemini.csx.cam.ac.uk... >> < extreme_pedant_mode=ON > >> >> Not so. In Fortran 77, it was possible to allocate all memory statically, >> but it isn't generally possible. It can't be done in Fortran 90 or C. > ><even_more_extreme_pedant_mode=ON> > >It *can* be done in C - by avoiding malloc ;). > ><even_more_extreme_pedant_mode=OFF>I will skip the mode nesting, as things are getting ridiculous :-) Problem one: in C, there is no memory management beyond stack scoped except by using malloc. Any algorithm that requires more than that can't be done if you don't use malloc. Problem two: there are many library facilities that use malloc either explicitly or implicitly - including almost all I/O - you would have to avoid them, too. Regards, Nick Maclaren.
Regarding calculation of free memory
Started by ●September 28, 2005
Reply by ●October 2, 20052005-10-02
Reply by ●October 2, 20052005-10-02
In article <KyR%e.41367$VI6.15199@fe1.news.blueyonder.co.uk>, David Hopwood <david.nospam.hopwood@blueyonder.co.uk> wrote:>Nick Maclaren wrote: >> Also, of the memory management schemes that are lumped under the term of >> 'heap' ones, there are several that have deterministic behaviour and do >> not suffer from fragmentation. The simplest one is if all allocations >> are of the same size, and chains are used instead of arrays. >> >> The whole area of memory management schemes is sadly neglected, and >> much of garbage collection work is based on unrealistic assumptions, >> so much of what is currently believed isn't so. > >That's a worthlessly vague statement. As far as I can see, the problem isn't >lack of research; it's lack of application of that research in the most >commonly used systems.On the contrary - one of the main reasons that it hasn't been applied is the impracticality of the research. That was the case in 1965, and is the case today. A fairly good rule when you find that real engineers (and there are some real software engineers, even today, and used to be more) are ignoring the wonderful results that come out of 'scientific' research is to ask whether the research is actually addressing the whole of the problem that the engineers are faced with. Regards, Nick Maclaren.
Reply by ●October 2, 20052005-10-02
"Nick Maclaren" <nmm1@cus.cam.ac.uk> wrote in message news:dhp6mi$7u3$1@gemini.csx.cam.ac.uk...> > Problem two: there are many library facilities that use malloc either > explicitly or implicitly - including almost all I/O - you would have > to avoid them, too.I'm posting this from c.a.e - embedded (or OS-less) is my main area. One tends not to need such I/O functions therein. You're right, though - it certainly pays to be aware of the platform requirements of any such library function. Steve http://www.fivetrees.com
Reply by ●October 2, 20052005-10-02
Nick Maclaren wrote:> David Hopwood <david.nospam.hopwood@blueyonder.co.uk> wrote: >>Nick Maclaren wrote: >> >>>Also, of the memory management schemes that are lumped under the term of >>>'heap' ones, there are several that have deterministic behaviour and do >>>not suffer from fragmentation. The simplest one is if all allocations >>>are of the same size, and chains are used instead of arrays. >>> >>>The whole area of memory management schemes is sadly neglected, and >>>much of garbage collection work is based on unrealistic assumptions, >>>so much of what is currently believed isn't so. >> >>That's a worthlessly vague statement. As far as I can see, the problem isn't >>lack of research; it's lack of application of that research in the most >>commonly used systems. > > On the contrary - one of the main reasons that it hasn't been applied > is the impracticality of the research. That was the case in 1965, > and is the case today. A fairly good rule when you find that real > engineers (and there are some real software engineers, even today, > and used to be more) are ignoring the wonderful results that come > out of 'scientific' research is to ask whether the research is > actually addressing the whole of the problem that the engineers > are faced with.Does every research paper on memory management describe something practical? No. Does the research that has been done on memory management collectively address the problems that arise in real systems in a practical way, for those engineers that are prepared to do a bit of searching to find the papers relevant to those problems? Yes, it does. If you think otherwise, then be specific about the problems you think are not addressed. -- David Hopwood <david.nospam.hopwood@blueyonder.co.uk>
Reply by ●October 2, 20052005-10-02
"Nick Maclaren" <nmm1@cus.cam.ac.uk> wrote in message news:dhp6mi$7u3$1@gemini.csx.cam.ac.uk...> In article <5pCdnWbp1rsoKaLeRVnyuw@pipex.net>, > Steve at fivetrees <steve@NOSPAMTAfivetrees.com> wrote: >>"Nick Maclaren" <nmm1@cus.cam.ac.uk> wrote in message >>news:dhobjl$e2v$1@gemini.csx.cam.ac.uk... >>> < extreme_pedant_mode=ON > >>> >>> Not so. In Fortran 77, it was possible to allocate all memory >>> statically, >>> but it isn't generally possible. It can't be done in Fortran 90 or C. >> >><even_more_extreme_pedant_mode=ON> >> >>It *can* be done in C - by avoiding malloc ;). >> >><even_more_extreme_pedant_mode=OFF> > > I will skip the mode nesting, as things are getting ridiculous :-) > > Problem one: in C, there is no memory management beyond stack scoped > except by using malloc. Any algorithm that requires more than that > can't be done if you don't use malloc.sbrk()?> Problem two: there are many library facilities that use malloc either > explicitly or implicitly - including almost all I/O - you would have > to avoid them, too.Provide your own malloc() so the I/O that needs it will get it from your own memory pool. Since you are doing the I/O, you can provide optimal buffering. -- ... Hank http://home.earthlink.net/~horedson http://home.earthlink.net/~w0rli
Reply by ●October 3, 20052005-10-03
In article <aNmdnfsCnNylr93enZ2dnUVZ8qmdnZ2d@pipex.net>, Steve at fivetrees <steve@NOSPAMTAfivetrees.com> wrote:>"Nick Maclaren" <nmm1@cus.cam.ac.uk> wrote in message >news:dhp6mi$7u3$1@gemini.csx.cam.ac.uk... >> >> Problem two: there are many library facilities that use malloc either >> explicitly or implicitly - including almost all I/O - you would have >> to avoid them, too. > >I'm posting this from c.a.e - embedded (or OS-less) is my main area. One >tends not to need such I/O functions therein.And still less the internationalisation and wide character facilities :-) My experience of that area is that the worst problem is finding out when a compiler has chosen to implement some basic facility (e.g. a mathematical function) in a way that drags in completely unrelated junk from the library. But I have been usually trying to used hosted compilers in an embedded fashion - I would expect compilers designed for embedded use to be better. Regards, Nick Maclaren.
Reply by ●October 3, 20052005-10-03
In article <h1Y%e.49486$iW5.46400@fe3.news.blueyonder.co.uk>, David Hopwood <david.nospam.hopwood@blueyonder.co.uk> wrote:> >Does every research paper on memory management describe something practical? No. >Does the research that has been done on memory management collectively address >the problems that arise in real systems in a practical way, for those engineers >that are prepared to do a bit of searching to find the papers relevant to those >problems? Yes, it does. If you think otherwise, then be specific about the >problems you think are not addressed.I have, many times. You ignored the issues every time. Regards, Nick Maclaren.
Reply by ●October 3, 20052005-10-03
In article <fmY%e.6314$oc.4151@newsread2.news.pas.earthlink.net>, Hank Oredson <horedson@earthlink.net> wrote:>> >> Problem one: in C, there is no memory management beyond stack scoped >> except by using malloc. Any algorithm that requires more than that >> can't be done if you don't use malloc. > >sbrk()?Not in C - in fact, I can't think of any standard that it IS in, because it makes such extremely horrible assumptions about the implementation.>> Problem two: there are many library facilities that use malloc either >> explicitly or implicitly - including almost all I/O - you would have >> to avoid them, too. > >Provide your own malloc() so the I/O that needs it will get it >from your own memory pool. Since you are doing the I/O, >you can provide optimal buffering.No. Replacing malloc is not supported in C, and often breaks the nastier vendor and third-party libraries. The reason is that the suite of malloc-related functions is not independent, and they often use non-standard interfaces. Yes, I have done it, over many years - but it isn't something that I recommend to users. Or can :-( Regards, Nick Maclaren.
Reply by ●October 3, 20052005-10-03
In comp.arch Nick Maclaren <nmm1@cus.cam.ac.uk> wrote:> > No. Replacing malloc is not supported in C, and often breaks > the nastier vendor and third-party libraries. The reason is that > the suite of malloc-related functions is not independent, and they > often use non-standard interfaces.There are still systems where you can reasonably do so - shipping more than one possible malloc to use is a good hint for example.> > Yes, I have done it, over many years - but it isn't something that > I recommend to users. Or can :-( > > > Regards, > Nick Maclaren.-- Sander +++ Out of cheese error +++
Reply by ●October 3, 20052005-10-03
In article <1128335888.327425@haldjas.folklore.ee>, Sander Vesik <sander@haldjas.folklore.ee> writes: |> In comp.arch Nick Maclaren <nmm1@cus.cam.ac.uk> wrote: |> > |> > No. Replacing malloc is not supported in C, and often breaks |> > the nastier vendor and third-party libraries. The reason is that |> > the suite of malloc-related functions is not independent, and they |> > often use non-standard interfaces. |> |> There are still systems where you can reasonably do so - shipping |> more than one possible malloc to use is a good hint for example. It's a hint that the VENDOR can do it - but not that the application programmer can. Yes, an experienced hacker can, which was the basis of my remark that I can, but I can't advise users to. Also, are you aware of how often third-party libraries demand a particular one of those mallocs, either in their release notes or because they fall over with others? Regards, Nick Maclaren.
