Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #95194 > unrolled thread
| Started by | "Mr. Man-wai Chang" <toylet.toylet@gmail.com> |
|---|---|
| First post | 2016-10-24 02:20 +0800 |
| Last post | 2016-11-04 02:31 +0800 |
| Articles | 20 on this page of 78 — 14 participants |
Back to article view | Back to comp.lang.c
VC++ 2013, malloc() and free() "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-10-24 02:20 +0800
VC++ 2013, malloc() and free() asetofsymbols@gmail.com - 2016-10-23 11:44 -0700
Re: VC++ 2013, malloc() and free() "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-10-25 12:46 +0800
Re: VC++ 2013, malloc() and free() Melzzzzz <mel@zzzzz.com> - 2016-10-25 07:15 +0200
Re: VC++ 2013, malloc() and free() supercat@casperkitty.com - 2016-10-25 07:15 -0700
Re: VC++ 2013, malloc() and free() Melzzzzz <mel@zzzzz.com> - 2016-10-25 16:18 +0200
Re: VC++ 2013, malloc() and free() supercat@casperkitty.com - 2016-10-25 07:32 -0700
Re: VC++ 2013, malloc() and free() Melzzzzz <mel@zzzzz.com> - 2016-10-25 16:55 +0200
Re: VC++ 2013, malloc() and free() jameskuyper@verizon.net - 2016-10-25 08:07 -0700
Re: VC++ 2013, malloc() and free() "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-10-24 22:30 -0700
Re: VC++ 2013, malloc() and free() Melzzzzz <mel@zzzzz.com> - 2016-10-25 07:46 +0200
Re: VC++ 2013, malloc() and free() "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-10-25 17:54 -0700
Re: VC++ 2013, malloc() and free() "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-10-25 17:55 -0700
Re: VC++ 2013, malloc() and free() "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-10-25 22:32 +0800
Re: VC++ 2013, malloc() and free() Melzzzzz <mel@zzzzz.com> - 2016-10-25 16:46 +0200
Re: VC++ 2013, malloc() and free() "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-10-25 23:24 +0800
Re: VC++ 2013, malloc() and free() "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-10-25 23:52 +0800
Re: VC++ 2013, malloc() and free() supercat@casperkitty.com - 2016-10-25 08:01 -0700
Re: VC++ 2013, malloc() and free() Melzzzzz <mel@zzzzz.com> - 2016-10-25 17:23 +0200
Re: VC++ 2013, malloc() and free() supercat@casperkitty.com - 2016-10-25 09:09 -0700
Re: VC++ 2013, malloc() and free() Keith Thompson <kst-u@mib.org> - 2016-10-25 09:29 -0700
Re: VC++ 2013, malloc() and free() Melzzzzz <mel@zzzzz.com> - 2016-10-25 18:51 +0200
Re: VC++ 2013, malloc() and free() raltbos@xs4all.nl (Richard Bos) - 2016-10-27 19:54 +0000
Re: VC++ 2013, malloc() and free() supercat@casperkitty.com - 2016-10-27 15:06 -0700
Re: VC++ 2013, malloc() and free() Keith Thompson <kst-u@mib.org> - 2016-10-27 17:06 -0700
Re: VC++ 2013, malloc() and free() supercat@casperkitty.com - 2016-10-28 06:47 -0700
Re: VC++ 2013, malloc() and free() "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-10-29 23:16 +0800
Re: VC++ 2013, malloc() and free() supercat@casperkitty.com - 2016-10-29 09:35 -0700
Re: VC++ 2013, malloc() and free() "James R. Kuyper" <jameskuyper@verizon.net> - 2016-10-29 12:51 -0400
Re: VC++ 2013, malloc() and free() supercat@casperkitty.com - 2016-10-29 14:26 -0700
Re: VC++ 2013, malloc() and free() jameskuyper@verizon.net - 2016-10-29 15:27 -0700
Re: VC++ 2013, malloc() and free() supercat@casperkitty.com - 2016-10-29 17:11 -0700
Re: VC++ 2013, malloc() and free() Geoff <geoff@invalid.invalid> - 2016-10-31 13:01 -0700
Re: VC++ 2013, malloc() and free() Jerry Stuckle <jstucklex@attglobal.net> - 2016-10-31 16:35 -0400
Re: VC++ 2013, malloc() and free() "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-01 15:31 +0800
Re: VC++ 2013, malloc() and free() Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-01 11:28 -0400
Re: VC++ 2013, malloc() and free() Geoff <geoff@invalid.invalid> - 2016-10-31 12:11 -0700
Re: VC++ 2013, malloc() and free() supercat@casperkitty.com - 2016-10-31 13:08 -0700
Re: VC++ 2013, malloc() and free() Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-23 21:35 +0100
Re: VC++ 2013, malloc() and free() "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-10-25 12:49 +0800
Re: VC++ 2013, malloc() and free() Melzzzzz <mel@zzzzz.com> - 2016-10-25 07:16 +0200
Re: VC++ 2013, malloc() and free() "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-10-25 22:30 +0800
Re: VC++ 2013, malloc() and free() "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-10-23 15:52 -0700
Re: VC++ 2013, malloc() and free() "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-10-25 12:50 +0800
Re: VC++ 2013, malloc() and free() Melzzzzz <mel@zzzzz.com> - 2016-10-25 07:18 +0200
Re: VC++ 2013, malloc() and free() "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-10-25 22:28 +0800
Re: VC++ 2013, malloc() and free() Melzzzzz <mel@zzzzz.com> - 2016-10-25 16:48 +0200
Re: VC++ 2013, malloc() and free() "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-10-25 23:25 +0800
Re: VC++ 2013, malloc() and free() Melzzzzz <mel@zzzzz.com> - 2016-10-25 17:35 +0200
Re: VC++ 2013, malloc() and free() "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-10-25 23:50 +0800
Re: VC++ 2013, malloc() and free() Melzzzzz <mel@zzzzz.com> - 2016-10-25 18:45 +0200
Re: VC++ 2013, malloc() and free() "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-10-26 01:59 +0800
Re: VC++ 2013, malloc() and free() Geoff <geoff@invalid.invalid> - 2016-10-31 12:10 -0700
Re: VC++ 2013, malloc() and free() "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-01 15:32 +0800
Re: VC++ 2013, malloc() and free() Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-01 11:31 -0400
Re: VC++ 2013, malloc() and free() "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-03 19:28 +0800
Re: VC++ 2013, malloc() and free() Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-03 10:00 -0400
Re: VC++ 2013, malloc() and free() "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-03 23:25 +0800
Re: VC++ 2013, malloc() and free() Keith Thompson <kst-u@mib.org> - 2016-11-03 09:03 -0700
[OT] "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-04 02:33 +0800
Re: [OT] Keith Thompson <kst-u@mib.org> - 2016-11-03 12:26 -0700
Re: [OT] "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-04 12:05 +0800
Re: [OT] luser droog <luser.droog@gmail.com> - 2016-11-03 21:52 -0700
Re: [OT] "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-04 21:59 +0800
Re: [OT] Keith Thompson <kst-u@mib.org> - 2016-11-04 08:45 -0700
Re: [OT] James Kuyper <jameskuyper@verizon.net> - 2016-11-04 11:49 -0400
Re: [OT] "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-05 00:33 +0800
Re: [OT] Keith Thompson <kst-u@mib.org> - 2016-11-04 09:56 -0700
Re: [OT] "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-05 01:40 +0800
Re: [OT] "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-05 01:42 +0800
Re: [OT] Keith Thompson <kst-u@mib.org> - 2016-11-04 11:52 -0700
Re: [OT] "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-05 18:13 +0800
Re: [OT] Keith Thompson <kst-u@mib.org> - 2016-11-05 13:19 -0700
Re: [OT] "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-06 16:00 +0800
Re: VC++ 2013, malloc() and free() Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-03 20:16 -0400
Re: VC++ 2013, malloc() and free() "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-05 00:34 +0800
Re: VC++ 2013, malloc() and free() supercat@casperkitty.com - 2016-11-03 08:54 -0700
Re: VC++ 2013, malloc() and free() "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-04 02:31 +0800
Page 1 of 4 [1] 2 3 4 Next page →
| From | "Mr. Man-wai Chang" <toylet.toylet@gmail.com> |
|---|---|
| Date | 2016-10-24 02:20 +0800 |
| Subject | VC++ 2013, malloc() and free() |
| Message-ID | <nuiv18$7cr$6@dont-email.me> |
My old school C programming told me to always clean up malloc() with corresponding calls to free() when my program exited. Is it safe to assume that VC++ in Visual Studio 2013 would always free all memory allocated by a C program, that I don't need to free them myself? Or is it actually the function of Window$ the OS? -- @~@ Remain silent! Drink, Blink, Stretch! Live long and prosper!! / v \ Simplicity is Beauty! /( _ )\ May the Force and farces be with you! ^ ^ (x86_64 Ubuntu 9.10) Linux 2.6.39.3 不借貸! 不詐騙! 不援交! 不打交! 不打劫! 不自殺! 請考慮綜援 (CSSA): http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa
[toc] | [next] | [standalone]
| From | asetofsymbols@gmail.com |
|---|---|
| Date | 2016-10-23 11:44 -0700 |
| Message-ID | <50ddf174-e477-4b57-b576-a17623b2ce68@googlegroups.com> |
| In reply to | #95194 |
It sees to me in window os when the program end, the sys free all memory of the program, one use free() or one not use free()... When program run instead, even if one use free() it is possible that memory is not free for the os...
[toc] | [prev] | [next] | [standalone]
| From | "Mr. Man-wai Chang" <toylet.toylet@gmail.com> |
|---|---|
| Date | 2016-10-25 12:46 +0800 |
| Message-ID | <numo37$2l9$3@dont-email.me> |
| In reply to | #95197 |
On 10/24/2016 2:44 AM, asetofsymbols@gmail.com wrote: > It sees to me in window os when the program end, the sys free all memory of the program, one use free() or one not use free()... When program run instead, even if one use free() it is possible that memory is not free for the os... > I did some Google Search on this topic. Some claimed that CPU cycles would be wasted if you called free() in your program given the fact Window$ would always free the memory a program requested. :) -- @~@ Remain silent! Drink, Blink, Stretch! Live long and prosper!! / v \ Simplicity is Beauty! /( _ )\ May the Force and farces be with you! ^ ^ (x86_64 Ubuntu 9.10) Linux 2.6.39.3 不借貸! 不詐騙! 不援交! 不打交! 不打劫! 不自殺! 請考慮綜援 (CSSA): http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2016-10-25 07:15 +0200 |
| Message-ID | <20161025071544.6dd3b8d6@maxa-pc.cpe.bvcom.net> |
| In reply to | #95253 |
On Tue, 25 Oct 2016 12:46:53 +0800 "Mr. Man-wai Chang" <toylet.toylet@gmail.com> wrote: > On 10/24/2016 2:44 AM, asetofsymbols@gmail.com wrote: > > It sees to me in window os when the program end, the sys free all > > memory of the program, one use free() or one not use free()... When > > program run instead, even if one use free() it is possible that > > memory is not free for the os... > > I did some Google Search on this topic. Some claimed that CPU cycles > would be wasted if you called free() in your program given the fact > Window$ would always free the memory a program requested. :) > Hm, then GC wastes lot of CPU cycles performing clean up. -- press any key to continue or any other to quit
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-10-25 07:15 -0700 |
| Message-ID | <b1ed8ae0-cbfb-4e75-8db0-00a222660138@googlegroups.com> |
| In reply to | #95260 |
On Tuesday, October 25, 2016 at 12:15:53 AM UTC-5, Melzzzzz wrote:> > I did some Google Search on this topic. Some claimed that CPU cycles > > would be wasted if you called free() in your program given the fact > > Window$ would always free the memory a program requested. :) > > > > Hm, then GC wastes lot of CPU cycles performing clean up. Uh, no it doesn't. Any decent malloc() implementation on a Windows machine will request memory from the OS in large chunks and then dole it out to the application in smaller chunks. Calling free() will add storage into a list of space that has been received from the operating system and is available for future calls to malloc(). When a program finishes, the operating system won't care about what the program has done with its blocks, or what portions it had marked as available for its own reuse. The OS will simply mark all of the "big" blocks it had given to the allocation as available for reuse. Although calling free() on every allocated block before exiting may make it easier to diagnose memory leaks [if a program is expected to have done so, but some blocks remain allocated, that will indicate that something that was expected to have been freed, wasn't] and while it's useful to allow programs to be incorporated into other programs, for the scenario of a program being run from a typical OS best efficiency would be obtained by not having applications bothering with free() unless they themselves are going to have use for the memory released thereby.
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2016-10-25 16:18 +0200 |
| Message-ID | <20161025161851.6d657301@maxa-pc.cpe.bvcom.net> |
| In reply to | #95271 |
On Tue, 25 Oct 2016 07:15:11 -0700 (PDT) supercat@casperkitty.com wrote: > On Tuesday, October 25, 2016 at 12:15:53 AM UTC-5, Melzzzzz wrote:> > > I did some Google Search on this topic. Some claimed that CPU cycles > > > would be wasted if you called free() in your program given the > > > fact Window$ would always free the memory a program requested. :) > > > > > > > Hm, then GC wastes lot of CPU cycles performing clean up. > > Uh, no it doesn't. Any decent malloc() implementation on a Windows > machine will request memory from the OS in large chunks and then dole > it out to the application in smaller chunks. Calling free() will add > storage into a list of space that has been received from the > operating system and is available for future calls to malloc(). When > a program finishes, the operating system won't care about what the > program has done with its blocks, or what portions it had marked as > available for its own reuse. The OS will simply mark all of the > "big" blocks it had given to the allocation as available for reuse. > Although calling free() on every allocated block before exiting may > make it easier to diagnose memory leaks [if a program is expected to > have done so, but some blocks remain allocated, that will indicate > that something that was expected to have been freed, wasn't] and > while it's useful to allow programs to be incorporated into other > programs, for the scenario of a program being run from a typical OS > best efficiency would be obtained by not having applications > bothering with free() unless they themselves are going to have use > for the memory released thereby. I talked about garbage collector. -- press any key to continue or any other to quit
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-10-25 07:32 -0700 |
| Message-ID | <7815aa7e-f328-4994-ba9e-5b03949fc91a@googlegroups.com> |
| In reply to | #95272 |
On Tuesday, October 25, 2016 at 9:19:00 AM UTC-5, Melzzzzz wrote: > > Uh, no it doesn't. Any decent malloc() implementation on a Windows > > machine will request memory from the OS in large chunks and then dole > > it out to the application in smaller chunks. Calling free() will add > > storage into a list of space that has been received from the > > operating system and is available for future calls to malloc(). When > > a program finishes, the operating system won't care about what the > > program has done with its blocks, or what portions it had marked as > > available for its own reuse. The OS will simply mark all of the > > "big" blocks it had given to the allocation as available for reuse. > > Although calling free() on every allocated block before exiting may > > make it easier to diagnose memory leaks [if a program is expected to > > have done so, but some blocks remain allocated, that will indicate > > that something that was expected to have been freed, wasn't] and > > while it's useful to allow programs to be incorporated into other > > programs, for the scenario of a program being run from a typical OS > > best efficiency would be obtained by not having applications > > bothering with free() unless they themselves are going to have use > > for the memory released thereby. > > I talked about garbage collector. The set of blocks the OS cleanup logic will need to handle will generally be the same regardless of whether the application calls free() or not.
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2016-10-25 16:55 +0200 |
| Message-ID | <20161025165527.6ef70fd4@maxa-pc.cpe.bvcom.net> |
| In reply to | #95277 |
On Tue, 25 Oct 2016 07:32:50 -0700 (PDT) supercat@casperkitty.com wrote: > On Tuesday, October 25, 2016 at 9:19:00 AM UTC-5, Melzzzzz wrote: > > > Uh, no it doesn't. Any decent malloc() implementation on a > > > Windows machine will request memory from the OS in large chunks > > > and then dole it out to the application in smaller chunks. > > > Calling free() will add storage into a list of space that has > > > been received from the operating system and is available for > > > future calls to malloc(). When a program finishes, the operating > > > system won't care about what the program has done with its > > > blocks, or what portions it had marked as available for its own > > > reuse. The OS will simply mark all of the "big" blocks it had > > > given to the allocation as available for reuse. Although calling > > > free() on every allocated block before exiting may make it easier > > > to diagnose memory leaks [if a program is expected to have done > > > so, but some blocks remain allocated, that will indicate that > > > something that was expected to have been freed, wasn't] and while > > > it's useful to allow programs to be incorporated into other > > > programs, for the scenario of a program being run from a typical > > > OS best efficiency would be obtained by not having applications > > > bothering with free() unless they themselves are going to have > > > use for the memory released thereby. > > > > I talked about garbage collector. > > The set of blocks the OS cleanup logic will need to handle will > generally be the same regardless of whether the application calls > free() or not. No, I meant cleanup runs of GC. Is that wasting of CPU cycles? -- press any key to continue or any other to quit
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2016-10-25 08:07 -0700 |
| Message-ID | <c12a4061-85c3-4f3d-b4b3-70653a9c837f@googlegroups.com> |
| In reply to | #95277 |
On Tuesday, October 25, 2016 at 10:33:10 AM UTC-4, supe...@casperkitty.com wrote: > On Tuesday, October 25, 2016 at 9:19:00 AM UTC-5, Melzzzzz wrote: ... > > I talked about garbage collector. > > The set of blocks the OS cleanup logic will need to handle will generally > be the same regardless of whether the application calls free() or not. The context is comparison of Program 1: allocates memory using malloc(), and explicitly deallocates it by calling free() as soon as possible after the memory is no longer needed. Program 2: allocates memory using malloc(), and never free()s it, counting on the cleanup that occurs automatically at the end of the program. Program 3: allocates memory using a different function, let's call it gc_malloc(), and never explicitly deallocates it, counting on the garbage collector to implicitly deallocate it as soon as it notices that it's no longer needed. The claim was that program 2 could be significantly faster than program 1, because deallocation during the run of the program is significantly slower than deallocation at the end. But in terms of deallocation, program 3 looks a lot more like program 1 than program 2, because the garbage collector will often be able to identify that memory is no longer needed, not too long after it actually is no longer needed. As a result, if program 2 is significantly faster than program 1, it should also be significantly faster than program 3, since program 3 will deallocate a lot of the same pieces of memory before the program ends that program 1 does.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2016-10-24 22:30 -0700 |
| Message-ID | <numqlc$92b$1@dont-email.me> |
| In reply to | #95253 |
On 10/24/2016 9:46 PM, Mr. Man-wai Chang wrote: > On 10/24/2016 2:44 AM, asetofsymbols@gmail.com wrote: >> It sees to me in window os when the program end, the sys free all >> memory of the program, one use free() or one not use free()... When >> program run instead, even if one use free() it is possible that memory >> is not free for the os... >> > > I did some Google Search on this topic. Some claimed that CPU cycles > would be wasted if you called free() in your program given the fact > Window$ would always free the memory a program requested. :) Calling free() is just prudent, and the right thing to do. Windows will free resources after the program has ended... But, what if you are creating a program that is designed to run for very long periods of time? You do not want it to crap out at some random point because you forgot to clean up after yourself. Right?
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2016-10-25 07:46 +0200 |
| Message-ID | <20161025074618.4e250bf3@maxa-pc.cpe.bvcom.net> |
| In reply to | #95263 |
On Mon, 24 Oct 2016 22:30:42 -0700 "Chris M. Thomasson" <invalid@invalid.invalid> wrote: > On 10/24/2016 9:46 PM, Mr. Man-wai Chang wrote: > > On 10/24/2016 2:44 AM, asetofsymbols@gmail.com wrote: > >> It sees to me in window os when the program end, the sys free all > >> memory of the program, one use free() or one not use free()... When > >> program run instead, even if one use free() it is possible that > >> memory is not free for the os... > >> > > > > I did some Google Search on this topic. Some claimed that CPU cycles > > would be wasted if you called free() in your program given the fact > > Window$ would always free the memory a program requested. :) > > Calling free() is just prudent, and the right thing to do. Windows > will free resources after the program has ended... But, what if you > are creating a program that is designed to run for very long periods > of time? You do not want it to crap out at some random point because > you forgot to clean up after yourself. Right? I think that people who don't like free have better luck with GC ;) Boehms GC is free and available... -- press any key to continue or any other to quit
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2016-10-25 17:54 -0700 |
| Message-ID | <nuour6$gkv$1@dont-email.me> |
| In reply to | #95265 |
On 10/24/2016 10:46 PM, Melzzzzz wrote: > On Mon, 24 Oct 2016 22:30:42 -0700 > "Chris M. Thomasson" <invalid@invalid.invalid> wrote: > >> On 10/24/2016 9:46 PM, Mr. Man-wai Chang wrote: >>> On 10/24/2016 2:44 AM, asetofsymbols@gmail.com wrote: >>>> It sees to me in window os when the program end, the sys free all >>>> memory of the program, one use free() or one not use free()... When >>>> program run instead, even if one use free() it is possible that >>>> memory is not free for the os... >>>> >>> >>> I did some Google Search on this topic. Some claimed that CPU cycles >>> would be wasted if you called free() in your program given the fact >>> Window$ would always free the memory a program requested. :) >> >> Calling free() is just prudent, and the right thing to do. Windows >> will free resources after the program has ended... But, what if you >> are creating a program that is designed to run for very long periods >> of time? You do not want it to crap out at some random point because >> you forgot to clean up after yourself. Right? > > I think that people who don't like free have better luck with GC ;) > Boehms GC is free and available... The funny thing is that one can really improve the performance of GC by using some manual allocation techniques in key places. Simple things like free-lists can take a lot of pressure of a GC. ;^)
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2016-10-25 17:55 -0700 |
| Message-ID | <nuoutd$gkv$2@dont-email.me> |
| In reply to | #95321 |
On 10/25/2016 5:54 PM, Chris M. Thomasson wrote: > On 10/24/2016 10:46 PM, Melzzzzz wrote: >> On Mon, 24 Oct 2016 22:30:42 -0700 >> "Chris M. Thomasson" <invalid@invalid.invalid> wrote: >> >>> On 10/24/2016 9:46 PM, Mr. Man-wai Chang wrote: >>>> On 10/24/2016 2:44 AM, asetofsymbols@gmail.com wrote: >>>>> It sees to me in window os when the program end, the sys free all >>>>> memory of the program, one use free() or one not use free()... When >>>>> program run instead, even if one use free() it is possible that >>>>> memory is not free for the os... >>>>> >>>> >>>> I did some Google Search on this topic. Some claimed that CPU cycles >>>> would be wasted if you called free() in your program given the fact >>>> Window$ would always free the memory a program requested. :) >>> >>> Calling free() is just prudent, and the right thing to do. Windows >>> will free resources after the program has ended... But, what if you >>> are creating a program that is designed to run for very long periods >>> of time? You do not want it to crap out at some random point because >>> you forgot to clean up after yourself. Right? >> >> I think that people who don't like free have better luck with GC ;) >> Boehms GC is free and available... > > The funny thing is that one can really improve the performance of GC by > using some manual allocation techniques in key places. > Simple things like free-lists can take a lot of pressure of a GC. I meant: Simple things like free-lists can take a lot of pressure _off_ a GC.
[toc] | [prev] | [next] | [standalone]
| From | "Mr. Man-wai Chang" <toylet.toylet@gmail.com> |
|---|---|
| Date | 2016-10-25 22:32 +0800 |
| Message-ID | <nunqd2$c2l$5@dont-email.me> |
| In reply to | #95263 |
On 10/25/2016 1:30 PM, Chris M. Thomasson wrote:
> Calling free() is just prudent, and the right thing to do. Windows will
> free resources after the program has ended... But, what if you are
> creating a program that is designed to run for very long periods of
> time? You do not want it to crap out at some random point because you
> forgot to clean up after yourself. Right?
What would happen if someone do this:
char *xx;
while (1) {
xx=malloc(_LARGE_NUMBER_);
free(xx);
}
Would the operating system crash? :)
--
@~@ Remain silent! Drink, Blink, Stretch! Live long and prosper!!
/ v \ Simplicity is Beauty!
/( _ )\ May the Force and farces be with you!
^ ^ (x86_64 Ubuntu 9.10) Linux 2.6.39.3
不借貸! 不詐騙! 不援交! 不打交! 不打劫! 不自殺! 請考慮綜援 (CSSA):
http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2016-10-25 16:46 +0200 |
| Message-ID | <20161025164603.1493a866@maxa-pc.cpe.bvcom.net> |
| In reply to | #95276 |
On Tue, 25 Oct 2016 22:32:25 +0800
"Mr. Man-wai Chang" <toylet.toylet@gmail.com> wrote:
> On 10/25/2016 1:30 PM, Chris M. Thomasson wrote:
> > Calling free() is just prudent, and the right thing to do. Windows
> > will free resources after the program has ended... But, what if you
> > are creating a program that is designed to run for very long
> > periods of time? You do not want it to crap out at some random
> > point because you forgot to clean up after yourself. Right?
>
> What would happen if someone do this:
>
> char *xx;
> while (1) {
> xx=malloc(_LARGE_NUMBER_);
> free(xx);
> }
>
> Would the operating system crash? :)
>
That would be ok.
--
press any key to continue or any other to quit
[toc] | [prev] | [next] | [standalone]
| From | "Mr. Man-wai Chang" <toylet.toylet@gmail.com> |
|---|---|
| Date | 2016-10-25 23:24 +0800 |
| Message-ID | <nunte2$omo$1@dont-email.me> |
| In reply to | #95278 |
On 10/25/2016 10:46 PM, Melzzzzz wrote:
>> What would happen if someone do this:
>>
>> char *xx;
>> while (1) {
>> xx=malloc(_LARGE_NUMBER_);
>> free(xx);
>> }
>>
>> Would the operating system crash? :)
>>
>
> That would be ok.
>
ON second thought, it's not C programming problem, but the design of
operating systems.
--
@~@ Remain silent! Drink, Blink, Stretch! Live long and prosper!!
/ v \ Simplicity is Beauty!
/( _ )\ May the Force and farces be with you!
^ ^ (x86_64 Ubuntu 9.10) Linux 2.6.39.3
不借貸! 不詐騙! 不援交! 不打交! 不打劫! 不自殺! 請考慮綜援 (CSSA):
http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa
[toc] | [prev] | [next] | [standalone]
| From | "Mr. Man-wai Chang" <toylet.toylet@gmail.com> |
|---|---|
| Date | 2016-10-25 23:52 +0800 |
| Message-ID | <nunv2u$uds$3@dont-email.me> |
| In reply to | #95287 |
On 10/25/2016 11:24 PM, Mr. Man-wai Chang wrote: > > ON second thought, it's not C programming problem, but the design of > operating systems. No, the actual implementation of a design can be different from each other. So it's not just the design, but the coding of the operating systems. -- @~@ Remain silent! Drink, Blink, Stretch! Live long and prosper!! / v \ Simplicity is Beauty! /( _ )\ May the Force and farces be with you! ^ ^ (x86_64 Ubuntu 9.10) Linux 2.6.39.3 不借貸! 不詐騙! 不援交! 不打交! 不打劫! 不自殺! 請考慮綜援 (CSSA): http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-10-25 08:01 -0700 |
| Message-ID | <b6e17bc9-cb19-4322-8004-53e962259bf6@googlegroups.com> |
| In reply to | #95276 |
On Tuesday, October 25, 2016 at 9:32:33 AM UTC-5, Mr. Man-wai Chang wrote:
> What would happen if someone do this:
>
> char *xx;
> while (1) {
> xx=malloc(_LARGE_NUMBER_);
> free(xx);
> }
>
> Would the operating system crash? :)
A typical malloc/free implementation will keep a list of blocks of memory
which are known to be available for use, but are not presently used for
any purpose. If a block large enough to satisfy the malloc() request is
available, malloc() will remove that block from the list but add back any
portion of it which isn't needed by the malloc() request [so if there was
a 49K block and malloc asks for 1000 bytes, a that 49K block might get
removed from the list and replaced with a roughly-48K block. If there
isn't enough space available, malloc() will ask for a chunk of memory from
the OS which is at least large enough to satisfy the request, but typically
much bigger, and then add whatever portion of that isn't needed by the
malloc request to the free list.
If code repeatedly allocates and frees the same object, there will
generally be no problem, since freeing the object will make the space it
had occupied available for a future malloc.
Even if insufficient memory is available to handle allocation requests, some
systems will have malloc() return null rather than jeopardize the stability
of the OS. I'm not quite sure why it's not fashionable for Unix to do so.
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2016-10-25 17:23 +0200 |
| Message-ID | <20161025172315.44bb53a4@maxa-pc.cpe.bvcom.net> |
| In reply to | #95284 |
On Tue, 25 Oct 2016 08:01:27 -0700 (PDT) supercat@casperkitty.com wrote: > > Even if insufficient memory is available to handle allocation > requests, some systems will have malloc() return null rather than > jeopardize the stability of the OS. I'm not quite sure why it's not > fashionable for Unix to do so. Malloc is not part of the system, usually. If you think about overcommit it is necessary on some setups, especially for GarbageCollector based programs. -- press any key to continue or any other to quit
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-10-25 09:09 -0700 |
| Message-ID | <52ae27e2-0157-4f29-8ca8-cbd656f32247@googlegroups.com> |
| In reply to | #95286 |
On Tuesday, October 25, 2016 at 10:23:23 AM UTC-5, Melzzzzz wrote: > Malloc is not part of the system, usually. > If you think about overcommit it is necessary on some setups, > especially for GarbageCollector based programs. I'm not clear on the advantages of overcommitting storage. I can understand that if code allocates memory it may be advantageous for a paging system to defer mapping it to physical page of RAM or assigning its physical location in the paging file until code is going to use it, but I would think it should be possible to keep track of the quantity of outstanding requests and start refusing requests as soon as the number of outstanding request matches the number of free blocks remaining. Trying to handle allocation failures when they occur is ugly, but it's at least possible to write code to recover from allocation failures somewhat gracefully. If a call to malloc() may yield a pointer to an address that could cause a critical failure when code tries to use it, and if there's no requirement that applications be able to tell when malloc() might have done so, is there any way to write code that uses malloc() storage and is guaranteed not to invoke UB?
[toc] | [prev] | [next] | [standalone]
Page 1 of 4 [1] 2 3 4 Next page →
Back to top | Article view | comp.lang.c
csiph-web