Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #90419 > unrolled thread
| Started by | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| First post | 2016-07-15 23:36 +0200 |
| Last post | 2016-08-02 13:20 -0700 |
| Articles | 20 on this page of 164 — 22 participants |
Back to article view | Back to comp.lang.c
High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-15 23:36 +0200
Re: High level C supercat@casperkitty.com - 2016-07-15 15:17 -0700
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-16 09:09 +0200
Re: High level C supercat@casperkitty.com - 2016-07-17 20:02 -0700
Re: High level C Keith Thompson <kst-u@mib.org> - 2016-07-15 15:17 -0700
Re: High level C fir <profesor.fir@gmail.com> - 2016-07-31 23:55 -0700
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-15 23:27 +0100
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-16 09:13 +0200
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-16 02:07 -0700
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-16 11:07 +0100
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-16 03:29 -0700
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-16 13:40 +0100
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-17 11:57 +0530
Re: High level C BartC <bc@freeuk.com> - 2016-07-16 11:30 +0100
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-16 03:43 -0700
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-16 13:53 +0100
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-16 07:49 -0700
Re: High level C Jean-Marc Bourguet <jm@bourguet.org> - 2016-07-16 17:08 +0200
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-16 09:09 -0700
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-16 16:26 +0100
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-16 18:05 +0200
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-16 20:15 +0100
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-16 23:44 +0200
Re: High level C raltbos@xs4all.nl (Richard Bos) - 2016-07-23 19:39 +0000
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-23 22:58 +0200
Re: High level C raltbos@xs4all.nl (Richard Bos) - 2016-07-27 14:52 +0000
Re: High level C Richard Heathfield <rjh@cpax.org.uk> - 2016-07-27 16:29 +0100
Re: High level C raltbos@xs4all.nl (Richard Bos) - 2016-07-23 19:38 +0000
Re: High level C BartC <bc@freeuk.com> - 2016-07-16 14:17 +0100
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-16 13:46 +0100
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-17 12:05 +0530
Re: High level C BartC <bc@freeuk.com> - 2016-07-17 11:03 +0100
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-17 03:39 -0700
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-17 18:20 +0530
Re: High level C BartC <bc@freeuk.com> - 2016-07-17 14:00 +0100
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-17 23:13 +0530
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-17 20:14 +0200
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-17 20:14 +0100
Re: High level C BartC <bc@freeuk.com> - 2016-07-17 20:45 +0100
Re: High level C Gareth Owen <gwowen@gmail.com> - 2016-07-17 21:00 +0100
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-18 09:48 +0530
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-18 00:55 -0700
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-18 22:25 +0530
Re: High level C BartC <bc@freeuk.com> - 2016-07-18 11:40 +0100
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-18 05:05 -0700
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-18 22:59 +0530
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-18 22:50 +0530
Re: High level C BartC <bc@freeuk.com> - 2016-07-18 19:07 +0100
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-19 11:53 +0530
Re: High level C BartC <bc@freeuk.com> - 2016-07-19 11:15 +0100
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-19 14:00 +0100
Re: High level C BartC <bc@freeuk.com> - 2016-07-19 15:01 +0100
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-19 15:26 +0100
Re: High level C BartC <bc@freeuk.com> - 2016-07-19 15:57 +0100
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-19 17:13 +0100
Re: High level C BartC <bc@freeuk.com> - 2016-07-19 18:14 +0100
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-19 19:20 +0100
Re: High level C BartC <bc@freeuk.com> - 2016-07-19 19:46 +0100
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-20 02:44 +0100
Re: High level C BartC <bc@freeuk.com> - 2016-07-20 10:59 +0100
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-20 03:07 -0700
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-21 01:44 +0100
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-21 18:58 +0530
Re: High level C BartC <bc@freeuk.com> - 2016-07-21 17:20 +0100
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-21 20:52 +0100
Re: High level C BartC <bc@freeuk.com> - 2016-07-21 21:14 +0100
Re: High level C Keith Thompson <kst-u@mib.org> - 2016-07-21 13:23 -0700
Re: High level C BartC <bc@freeuk.com> - 2016-07-21 21:50 +0100
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-22 12:52 +0200
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-22 04:03 -0700
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-22 23:56 +0530
Re: High level C BartC <bc@freeuk.com> - 2016-07-22 20:09 +0100
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-22 23:49 +0530
Re: High level C BartC <bc@freeuk.com> - 2016-07-22 20:37 +0100
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-19 19:16 +0200
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-19 19:17 +0100
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-19 21:07 +0200
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-20 02:36 +0100
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-19 07:27 -0700
Re: High level C BartC <bc@freeuk.com> - 2016-07-19 16:27 +0100
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-19 08:43 -0700
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-19 19:14 +0100
Re: High level C Jean-Marc Bourguet <jm@bourguet.org> - 2016-07-18 10:08 +0200
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-18 23:04 +0530
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-16 10:18 +0100
Re: High level C raltbos@xs4all.nl (Richard Bos) - 2016-07-23 19:26 +0000
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-25 09:21 -0700
Re: High level C luser droog <luser.droog@gmail.com> - 2016-07-25 10:19 -0700
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-28 10:31 -0700
Re: High level C luser droog <luser.droog@gmail.com> - 2016-07-28 21:13 -0700
Re: High level C supercat@casperkitty.com - 2016-07-29 09:05 -0700
Re: High level C Keith Thompson <kst-u@mib.org> - 2016-07-29 09:30 -0700
Re: High level C supercat@casperkitty.com - 2016-07-29 10:08 -0700
Re: High level C Ike Naar <ike@iceland.freeshell.org> - 2016-07-29 17:57 +0000
Re: High level C supercat@casperkitty.com - 2016-07-29 11:50 -0700
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-31 07:16 -0700
Re: High level C raltbos@xs4all.nl (Richard Bos) - 2016-07-31 14:34 +0000
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-31 14:55 -0700
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-01 03:10 -0700
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-01 07:40 -0700
Re: High level C Gareth Owen <gwowen@gmail.com> - 2016-08-01 19:43 +0100
Re: High level C Les Cargill <lcargill99@comcast.com> - 2016-08-01 10:21 -0500
Re: High level C raltbos@xs4all.nl (Richard Bos) - 2016-08-03 13:14 +0000
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-05 08:40 -0700
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-05 09:28 -0700
Re: High level C fir <profesor.fir@gmail.com> - 2016-08-05 09:55 -0700
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-05 15:51 -0700
Re: High level C Melzzzzz <mel@zzzzz.com> - 2016-08-05 18:43 +0200
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-05 15:43 -0700
Re: High level C Melzzzzz <mel@zzzzz.com> - 2016-08-06 00:52 +0200
Re: High level C raltbos@xs4all.nl (Richard Bos) - 2016-08-10 12:42 +0000
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-11 12:24 -0700
Re: High level C Melzzzzz <mel@zzzzz.com> - 2016-07-31 16:42 +0200
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-31 12:59 -0700
Re: High level C Les Cargill <lcargill99@comcast.com> - 2016-07-31 17:12 -0500
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-31 17:12 -0700
Re: High level C Les Cargill <lcargill99@comcast.com> - 2016-08-01 00:54 -0500
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-01 08:08 -0700
Re: High level C Les Cargill <lcargill99@comcast.com> - 2016-08-01 12:58 -0500
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-01 12:25 -0700
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-03 08:44 -0700
Re: High level C Les Cargill <lcargill99@comcast.com> - 2016-08-03 11:56 -0500
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-03 19:29 +0200
Re: High level C "James R. Kuyper" <jameskuyper@verizon.net> - 2016-08-03 13:45 -0400
Re: High level C Les Cargill <lcargill99@comcast.com> - 2016-08-03 13:23 -0500
Re: High level C BartC <bc@freeuk.com> - 2016-08-03 19:27 +0100
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-03 21:04 +0200
Re: High level C Gareth Owen <gwowen@gmail.com> - 2016-08-03 20:08 +0100
Re: High level C Les Cargill <lcargill99@comcast.com> - 2016-08-03 16:09 -0500
Re: High level C Les Cargill <lcargill99@comcast.com> - 2016-08-03 16:06 -0500
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-03 23:36 +0200
Re: High level C Les Cargill <lcargill99@comcast.com> - 2016-08-03 19:44 -0500
Re: High level C supercat@casperkitty.com - 2016-08-03 15:03 -0700
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-04 19:17 -0700
Re: High level C Melzzzzz <mel@zzzzz.com> - 2016-08-05 05:48 +0200
Re: High level C Keith Thompson <kst-u@mib.org> - 2016-08-05 08:24 -0700
Re: High level C Melzzzzz <mel@zzzzz.com> - 2016-08-05 18:30 +0200
Re: High level C Keith Thompson <kst-u@mib.org> - 2016-08-05 10:34 -0700
Re: High level C Melzzzzz <mel@zzzzz.com> - 2016-08-05 20:50 +0200
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-05 15:39 -0700
Re: High level C Melzzzzz <mel@zzzzz.com> - 2016-08-06 00:50 +0200
Re: High level C Keith Thompson <kst-u@mib.org> - 2016-08-05 17:08 -0700
Re: High level C Melzzzzz <mel@zzzzz.com> - 2016-08-06 02:23 +0200
Re: High level C raltbos@xs4all.nl (Richard Bos) - 2016-08-06 10:03 +0000
Re: High level C Melzzzzz <mel@zzzzz.com> - 2016-08-06 12:13 +0200
Re: High level C "James R. Kuyper" <jameskuyper@verizon.net> - 2016-08-06 11:10 -0400
Re: High level C Melzzzzz <mel@zzzzz.com> - 2016-08-06 17:40 +0200
Re: High level C "James R. Kuyper" <jameskuyper@verizon.net> - 2016-08-06 11:56 -0400
Re: High level C Melzzzzz <mel@zzzzz.com> - 2016-08-06 17:51 +0200
Re: High level C supercat@casperkitty.com - 2016-08-08 09:12 -0700
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-31 22:07 +0200
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-31 15:05 -0700
Re: High level C Ian Collins <ian-news@hotmail.com> - 2016-08-03 11:22 +1200
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-03 08:50 -0700
Re: High level C BartC <bc@freeuk.com> - 2016-07-16 01:12 +0100
Re: High level C Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-15 20:16 -0400
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-16 09:17 +0200
Re: High level C Siri Cruise <chine.bleu@yahoo.com> - 2016-07-16 08:20 -0700
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-16 17:24 +0200
Re: High level C Siri Cruise <chine.bleu@yahoo.com> - 2016-07-16 09:24 -0700
Re: High level C carlglassberg@gmail.com - 2016-07-17 14:15 -0700
Re: High level C carlglassberg@gmail.com - 2016-07-17 14:22 -0700
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-17 23:58 +0200
Re: High level C fir <profesor.fir@gmail.com> - 2016-08-02 13:20 -0700
Page 7 of 9 — ← Prev page 1 2 3 4 5 6 [7] 8 9 Next page →
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-08-03 08:44 -0700 |
| Message-ID | <kfn4m71kgc1.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #91504 |
Les Cargill <lcargill99@comcast.com> writes: > Tim Rentsch wrote: >> Les Cargill <lcargill99@comcast.com> writes: >> >>> Tim Rentsch wrote: >>>> Les Cargill <lcargill99@comcast.com> writes: >>>> >>>>> Tim Rentsch wrote: >>>>>> Melzzzzz <mel@zzzzz.com> writes: >>>>>> >>>>>>> On Sun, 31 Jul 2016 07:16:58 -0700 >>>>>>> Tim Rentsch <txr@alumni.caltech.edu> wrote: >>>>>>> >>>>>>>> There is a common belief in some circles that GC incurs a >>>>>>>> substantial performance penalty relative to manual coding of >>>>>>>> free(), etc. Experience with actual systems does not bear this >>>>>>>> out. Indeed, the experience in some large code bases has been >>>>>>>> that switching to GC actually improves performance. >>>>>>> >>>>>>> Care to show links? >>>>>> >>>>>> Unfortunately I don't know any. The only specific examples I >>>>>> know of are proprietary. I am not aware of any where the >>>>>> results are publically available. >>>>>> >>>>>>> I find hardly to believe that deallocation increase >>>>>>> performance... >>>>>>> Stopping program to perform memory scan and trashing memory in process >>>>>>> is faster? how so? >>>>>> >>>>>> I think it's pretty easy to understand. If you do manual >>>>>> deallocation, bookkeeping needs to be done to keep track of what >>>>>> is referenced to know when something can be deallocated. >>>>> >>>>> No, you simply have to have an explicit context for the lifetime of >>>>> objects. I personally have never witnessed where this was all that >>>>> onerous. Most things we do can be chunked into "frames" like that. >>>> >>>> Certainly that can be done in some cases. I believe there >>>> are also cases where it cannot be done, or at least cannot >>>> be done without a fair amount of difficulty. I didn't >>>> mean to say that getting a performance improvement is >>>> typical, only that it does sometimes occur in real cases. >>> >>> I'm not sure what you're after here. Most 'C' programs I've used >>> may use dynamic ( or, more probably semi-dynamic) allocation behind >>> the scenes but applications I've dealt with largely tended to >>> accumulate a set of buffers and working storage, and after a short >>> while, became memory-stable. >>> >>> For the curious, this does indeed include things that have significant >>> levels of dynamically configured objects that get created and >>> destroyed. You can often see the same sort of approach taken in the >>> Linux kernel - configuration options for the maximum number of object >>> <x> are part of the kernel build. This creates arrays that are then >>> dynamically used. >>> >>> This is just a very 'C' thing to do. >> >> Obviously the behavior depends a lot on the application. At one >> end of the spectrum, a program to do base64 encoding/decoding is >> likely to need essentially zero allocated memory. Closer to the >> other end of the spectrum, a web browser is going to need new >> memory every time a new web page is opened (and ideally discard >> it when the page is closed). > > So the total number of web browsers in the world probably fits in one > digit. This is hardly an argument for a language system providing all > the support for that level of dynamic-ness. This comment surprises me coming from you. All the applications named were meant only as examples in their respective areas of the spectrum. For the browser area, any large-scale, long-running application qualifies, and there are lots of those: databases, word processors, spreadsheets, even text editors. Let's say a code base of 250,000 lines or more. Naturally there won't be too many programs of that size, because anything of such a scale is a significant undertaking to develop. But they are disproportionally important for that very reason, and also because their nature requires them to be resiliant in the face of very long lifetimes. >> As a rule in my own browser usage, >> I always open news tabs, and hardly ever close them. (Of course >> I do close most of them eventually, but not right away.) > > I close them as soon as I'm done. I have little doubt that they leak > memory, at least in terms of how the instrumentation for "memory used" > is concerned. I can close the whole thing ( after individually closing > tabs) and memory used drops. But there's a hunk of the executable that > stays resident after. I agree with your observations about memory usage. I suspect (although of course I don't know) that some of the memory leak behaviors derives from being overly cautious about freeing memory that might still be in use. My experience (admittedly not very diverse) with web browers is that they never reach a point of being memory stable; at some point the browser has to be shut down and restarted, in order to get the ever-increasing amount of unused memory back. >> Somewhere in between the end points we might put a compiler. >> It starts off using a small amount of memory, and allocates as >> it reads more source. Then there is more allocation during >> semantic analysis to do type checking, optimization, checks >> for warning conditions, etc. Of course a compiler might adopt >> a strategy of simply never deallocating, which is probably >> workable in some cases. But that's just a poor man's GC - >> if a program is going to call malloc() and never call free(), >> assuming it doesn't hide pointers in some sneaky way then >> it might as well take advantage of drop-in conservative >> collector, which could allow it to compile larger programs >> than it could otherwise. > > "A compiler" is generally multiple executables. Each has a pretty > proscribed, even pipe-ey task to perform. They're kinda "stream in, > stream out" sorts of programs. That helps separate the different phases, but the same observation applies to the phases individually. And some information needs to be passed or replicated downstream, for example source location information, so error messages can be given. The key point is allocation has to be managed somehow, and potentially unbounded program source means potentially unbounded allocation for structures to represent that source. We might take the optimistic view that the code will simply allocate and never free(), which actually isn't an unreasonable choice in some situations. The question is what alternatives are available when we don't want to make that choice? >> Long story short: yes, it depends on the application. But >> in general the larger the application the more likely it is >> to be doing a lot of allocation and deallocation, and the >> more likely it is that deallocation doesn't follow an easily >> predictable pattern. > > So color me less than sympathetic. It all just sounds like people > throwing up their hands to me. > > If I have a point, it is that developing a culture of rational > ignorance about object lifetimes seems risky to me. I *perceive* this > as an artifact of people being...traumatized by memory leaks in their > CS 101 phase and becoming somewhat over-sensitive to it. Or something. > > In the larger scheme of things, it's a sufficiently proscribed > problem that we believe it can be automated, so it should not be too > much afraid of doing in in other ways, if that makes any sense in the > first place. I don't think GC is any sort of panacea. Using GC doesn't eliminate the need to think about how memory resources are used, and it would be foolish to pretend otherwise. Furthermore there are situations where a malloc/free discipline is a better choice, or even some more restrictive strategy. (IIRC Knuth chose a fixed-size allocation arena for TeX so that he could guarantee reproducible results on different systems.) I think there are people on both sides of the fence who believe GC is some sort of utopia (or "utopia"). It isn't. It is just as wrong to think GC should always be used as to think it should never be used. In talking about GC and advocating that it be available as an option in C, my goal is not to get people to adopt it blindly but to start a real conversation, to be able to talk about the pluses and minuses without getting bogged down in various misconceptions (here again, on both sides of the fence). I have no desire to develop a culture of rational ignorance - exactly the opposite. > And to be even more specific, I own things that obviously run Java and > they tend to be less reliable than the things that run 'C'. I have a > BluRay player and you have to unplug it from the wall now and again and > let all the "memory to go a ground state" type thing. I have experience with Java but essentially no experience with the Java community or Java culture. It may be that Java culture, or some parts of Java culture, take a naive view of how memory allocation should be dealt with (or not). If that is so then I would say that is a fault of the Java culture, not a fault of Java having automatic storage management. (In particular, Java has weak references in various forms. Java does not (yet?) have ephemerons, but AIUI there are proposals to add ephemerons to Java.) >> If we weight our samples by how many >> lines of code are involved, I think most of the code will >> allocating and deallocating a fair amount. Do you agree >> with that, or disagree? > > I have to admit that I only know on a shallow level. > > >> Your example of the Linux kernel is a good one. However, >> I think it is not typical of most large C programs. > > Yeah, it could easily be a bias - most things I do are closer to > your base64 converter. They may be in user space, but they tend to be > very "driver-ey". Clearly there are lots of cases, even whole categories of programs, where conventional management disciplines are a better choice than dragging in all the machinery needed for GC. Part of the reason for starting the discussion is to be able to talk about which are which.
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2016-08-03 11:56 -0500 |
| Message-ID | <nnt7d2$bpt$1@dont-email.me> |
| In reply to | #91605 |
Tim Rentsch wrote: > Les Cargill <lcargill99@comcast.com> writes: > >> Tim Rentsch wrote: >>> Les Cargill <lcargill99@comcast.com> writes: >>> >>>> Tim Rentsch wrote: >>>>> Les Cargill <lcargill99@comcast.com> writes: >>>>> >>>>>> Tim Rentsch wrote: >>>>>>> Melzzzzz <mel@zzzzz.com> writes: >>>>>>> >>>>>>>> On Sun, 31 Jul 2016 07:16:58 -0700 >>>>>>>> Tim Rentsch <txr@alumni.caltech.edu> wrote: >>>>>>>> >>>>>>>>> There is a common belief in some circles that GC incurs a >>>>>>>>> substantial performance penalty relative to manual coding of >>>>>>>>> free(), etc. Experience with actual systems does not bear this >>>>>>>>> out. Indeed, the experience in some large code bases has been >>>>>>>>> that switching to GC actually improves performance. >>>>>>>> >>>>>>>> Care to show links? >>>>>>> >>>>>>> Unfortunately I don't know any. The only specific examples I >>>>>>> know of are proprietary. I am not aware of any where the >>>>>>> results are publically available. >>>>>>> >>>>>>>> I find hardly to believe that deallocation increase >>>>>>>> performance... >>>>>>>> Stopping program to perform memory scan and trashing memory in process >>>>>>>> is faster? how so? >>>>>>> >>>>>>> I think it's pretty easy to understand. If you do manual >>>>>>> deallocation, bookkeeping needs to be done to keep track of what >>>>>>> is referenced to know when something can be deallocated. >>>>>> >>>>>> No, you simply have to have an explicit context for the lifetime of >>>>>> objects. I personally have never witnessed where this was all that >>>>>> onerous. Most things we do can be chunked into "frames" like that. >>>>> >>>>> Certainly that can be done in some cases. I believe there >>>>> are also cases where it cannot be done, or at least cannot >>>>> be done without a fair amount of difficulty. I didn't >>>>> mean to say that getting a performance improvement is >>>>> typical, only that it does sometimes occur in real cases. >>>> >>>> I'm not sure what you're after here. Most 'C' programs I've used >>>> may use dynamic ( or, more probably semi-dynamic) allocation behind >>>> the scenes but applications I've dealt with largely tended to >>>> accumulate a set of buffers and working storage, and after a short >>>> while, became memory-stable. >>>> >>>> For the curious, this does indeed include things that have significant >>>> levels of dynamically configured objects that get created and >>>> destroyed. You can often see the same sort of approach taken in the >>>> Linux kernel - configuration options for the maximum number of object >>>> <x> are part of the kernel build. This creates arrays that are then >>>> dynamically used. >>>> >>>> This is just a very 'C' thing to do. >>> >>> Obviously the behavior depends a lot on the application. At one >>> end of the spectrum, a program to do base64 encoding/decoding is >>> likely to need essentially zero allocated memory. Closer to the >>> other end of the spectrum, a web browser is going to need new >>> memory every time a new web page is opened (and ideally discard >>> it when the page is closed). >> >> So the total number of web browsers in the world probably fits in one >> digit. This is hardly an argument for a language system providing all >> the support for that level of dynamic-ness. > > This comment surprises me coming from you. All the applications > named were meant only as examples in their respective areas of > the spectrum. For the browser area, any large-scale, > long-running application qualifies, and there are lots of those: > databases, word processors, spreadsheets, even text editors. > Let's say a code base of 250,000 lines or more. Naturally there > won't be too many programs of that size, because anything of > such a scale is a significant undertaking to develop. But they > are disproportionally important for that very reason, and also > because their nature requires them to be resiliant in the face > of very long lifetimes. > The question I thought I was answering :) is "what's the value of the language system providing a rich GC functionality." >>> As a rule in my own browser usage, >>> I always open news tabs, and hardly ever close them. (Of course >>> I do close most of them eventually, but not right away.) >> >> I close them as soon as I'm done. I have little doubt that they leak >> memory, at least in terms of how the instrumentation for "memory used" >> is concerned. I can close the whole thing ( after individually closing >> tabs) and memory used drops. But there's a hunk of the executable that >> stays resident after. > > I agree with your observations about memory usage. I suspect > (although of course I don't know) that some of the memory > leak behaviors derives from being overly cautious about > freeing memory that might still be in use. My experience > (admittedly not very diverse) with web browers is that they > never reach a point of being memory stable; at some point > the browser has to be shut down and restarted, in order to > get the ever-increasing amount of unused memory back. > >>> Somewhere in between the end points we might put a compiler. >>> It starts off using a small amount of memory, and allocates as >>> it reads more source. Then there is more allocation during >>> semantic analysis to do type checking, optimization, checks >>> for warning conditions, etc. Of course a compiler might adopt >>> a strategy of simply never deallocating, which is probably >>> workable in some cases. But that's just a poor man's GC - >>> if a program is going to call malloc() and never call free(), >>> assuming it doesn't hide pointers in some sneaky way then >>> it might as well take advantage of drop-in conservative >>> collector, which could allow it to compile larger programs >>> than it could otherwise. >> >> "A compiler" is generally multiple executables. Each has a pretty >> proscribed, even pipe-ey task to perform. They're kinda "stream in, >> stream out" sorts of programs. > > That helps separate the different phases, but the same > observation applies to the phases individually. And some > information needs to be passed or replicated downstream, > for example source location information, so error messages > can be given. The key point is allocation has to be > managed somehow, and potentially unbounded program source > means potentially unbounded allocation for structures to > represent that source. We might take the optimistic view > that the code will simply allocate and never free(), which > actually isn't an unreasonable choice in some situations. > The question is what alternatives are available when we > don't want to make that choice? > >>> Long story short: yes, it depends on the application. But >>> in general the larger the application the more likely it is >>> to be doing a lot of allocation and deallocation, and the >>> more likely it is that deallocation doesn't follow an easily >>> predictable pattern. >> >> So color me less than sympathetic. It all just sounds like people >> throwing up their hands to me. >> >> If I have a point, it is that developing a culture of rational >> ignorance about object lifetimes seems risky to me. I *perceive* this >> as an artifact of people being...traumatized by memory leaks in their >> CS 101 phase and becoming somewhat over-sensitive to it. Or something. >> >> In the larger scheme of things, it's a sufficiently proscribed >> problem that we believe it can be automated, so it should not be too >> much afraid of doing in in other ways, if that makes any sense in the >> first place. > > I don't think GC is any sort of panacea. Using GC doesn't > eliminate the need to think about how memory resources are used, > and it would be foolish to pretend otherwise. Furthermore there > are situations where a malloc/free discipline is a better > choice, or even some more restrictive strategy. (IIRC Knuth > chose a fixed-size allocation arena for TeX so that he could > guarantee reproducible results on different systems.) I think > there are people on both sides of the fence who believe GC is > some sort of utopia (or "utopia"). It isn't. It is just as > wrong to think GC should always be used as to think it should > never be used. In talking about GC and advocating that it be > available as an option in C, my goal is not to get people to > adopt it blindly but to start a real conversation, to be able to > talk about the pluses and minuses without getting bogged down > in various misconceptions (here again, on both sides of the > fence). I have no desire to develop a culture of rational > ignorance - exactly the opposite. > Well, I'm guessing about how this came to pass, so I probably got it wrong. I am just skeptical of the value of GC in general. I don't fully comprehend how it is that doing memory allocation manually is onerous. I don't "do GUIs" so much ( just a little ) so I'm sure that accounts for a lot of the bias. What GUIs I have built use toolchains where objects are still allocated and deallocated in code. >> And to be even more specific, I own things that obviously run Java and >> they tend to be less reliable than the things that run 'C'. I have a >> BluRay player and you have to unplug it from the wall now and again and >> let all the "memory to go a ground state" type thing. > > I have experience with Java but essentially no experience with > the Java community or Java culture. It may be that Java culture, > or some parts of Java culture, take a naive view of how memory > allocation should be dealt with (or not). If that is so then I > would say that is a fault of the Java culture, not a fault of > Java having automatic storage management. (In particular, Java > has weak references in various forms. Java does not (yet?) have > ephemerons, but AIUI there are proposals to add ephemerons to > Java.) > I've seen enough to know that I wouldn't want Java in anything critical. >>> If we weight our samples by how many >>> lines of code are involved, I think most of the code will >>> allocating and deallocating a fair amount. Do you agree >>> with that, or disagree? >> >> I have to admit that I only know on a shallow level. >> >> >>> Your example of the Linux kernel is a good one. However, >>> I think it is not typical of most large C programs. >> >> Yeah, it could easily be a bias - most things I do are closer to >> your base64 converter. They may be in user space, but they tend to be >> very "driver-ey". > > Clearly there are lots of cases, even whole categories of > programs, where conventional management disciplines are a > better choice than dragging in all the machinery needed > for GC. Part of the reason for starting the discussion is > to be able to talk about which are which. > I expect that there are just different cultures, that people who expect 'C' to do GC aren't people who perhaps "should" be looking at 'C'. The competitors to 'C' these days are more on the line of Python and/or Rust. -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-08-03 19:29 +0200 |
| Message-ID | <nnt9lv$jj8$1@dont-email.me> |
| In reply to | #91610 |
Le 03/08/2016 à 18:56, Les Cargill a écrit : > I expect that there are just different cultures, that people who > expect 'C' to do GC aren't people who perhaps "should" be looking at 'C'. So, 'C' is for you exposing yourself to all the tedious work of freeing memory without having a single error? Look just an example: I wrote a debugger for my IDE (yes, I know that you do not like/use IDE's but bear with me) and the problem of WHO is going to free each buffer was consuming me all my time!!! The front end (the editor, the display of the source code, the disassembler and many other parts of the debugger) needed to communicate with the "back-end" that has all information about the program being debugged, information that has to pass through buffers and buffers all implementing some kind of abstraction. WHO allocated this buffer? I was tired of debugger crashes and decided to use the GC. It has never caused any problem, and the delays introduced by the GC are completely invisible. Of course, people that do not use IDEs (how do you debug stuff by the way? Using text mode gdb???) Your answer is typical of people that think that their prejudices are correct and jusrt do not want to understand that the world evolves, that software construction today is different from what it was in the time of the terminals!!!
[toc] | [prev] | [next] | [standalone]
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2016-08-03 13:45 -0400 |
| Message-ID | <416bb817-3316-5031-c9d1-e103ff28e467@verizon.net> |
| In reply to | #91611 |
On 08/03/2016 01:29 PM, jacobnavia wrote: ... > Of course, people that do not use IDEs (how do you debug stuff by the > way? Using text mode gdb???) Yes. I used to use dbx, which I found far easier to use, but we no longer use machines on which it is installed. The main part of that sentence was a long noun phrase, leading me to expect a verb for which that noun phrase would be a subject. No such verb ever arrived. Did you have something you wanted to say about such people? > Your answer is typical of people that think that their prejudices are > correct and jusrt do not want to understand that the world evolves, that > software construction today is different from what it was in the time of > the terminals!!! Your answer is typical of people who think that their prejudices are correct, and just do not want to understand that their preferred technology is not the inevitable result of software evolution, but instead has a usefulness that depends upon the context.
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2016-08-03 13:23 -0500 |
| Message-ID | <nntcht$u0n$1@dont-email.me> |
| In reply to | #91611 |
jacobnavia wrote: > Le 03/08/2016 à 18:56, Les Cargill a écrit : >> I expect that there are just different cultures, that people who >> expect 'C' to do GC aren't people who perhaps "should" be looking at 'C'. > > So, 'C' is for you exposing yourself to all the tedious work of freeing > memory without having a single error? > > Look just an example: > > I wrote a debugger for my IDE (yes, I know that you do not like/use > IDE's but bear with me) and the problem of WHO is going to free each > buffer was consuming me all my time!!! > > The front end (the editor, the display of the source code, the > disassembler and many other parts of the debugger) needed to communicate > with the "back-end" that has all information about the program being > debugged, information that has to pass through buffers and buffers all > implementing some kind of abstraction. > > WHO allocated this buffer? > So in general, the buffer itself should tell you that. It could be a property of the buffer, it could be implied by context, any of a number of things. Who owns it? Declare an enum of "whos" and add a header to buffers that tells you that. How can you claim any knowledge of the rough correct operation of a product if you can't reason effectively about object lifetime? > I was tired of debugger crashes and decided to use the GC. It has never > caused any problem, and the delays introduced by the GC are completely > invisible. > Well, there you go. Here is the thing: I think that had you considered this up front in your design, it would have been both easier and your project would have been more stable. I'm not nattering/complaining, it's just the many or most of the projects I've worked on that needed dynamic objects, I spent considerable time figuring out what was framed in what, how object lifetimes worked, that sort of thing. Maybe that's too much trouble for something like an IDE. I don't know. I do know that one reason I don't like IDEs is that many of them were pretty buggy. You have to understand: the code I write *HAS* to work. Every time, all the time. No exceptions. Using something like the Win32 API makes this problematic, but it's eminently doable. > Of course, people that do not use IDEs (how do you debug stuff by the > way? Using text mode gdb???) > I generally debug stuff by using instrumentation internal to the code base. Worst case is writing to log files or using printf(). I'll keep counters of things like events mainly. Then I'll write analysis tools that run on a workstation that figure out what's going on. People have said "oh, you're writing a debugger." No, not at all - this is specialized to the thing being written. It's a lot less than you think. I can debug stuff that's running in a production environment this way with no modification. But I get past the level of basic programming errors very early in a project. I'm down to people miscommunicating about interfaces and configuration issues. You use my stuff to figure out what everybody else has done wrong. > Your answer is typical of people that think that their prejudices are > correct Of course not. I've explained my position - again - in this post. I don't buy the idea that this is just too hard. I think people just want to stop worrying about it. Which is bizarre. Which is one reason I tend to avoid that sort of project. > and jusrt do not want to understand that the world evolves,that > software construction today is different from what it was in the time of > the terminals!!! If that were actually true, I might agree with you :) Nothing significant has changed, sadly. -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-08-03 19:27 +0100 |
| Message-ID | <nntd3a$hj$1@dont-email.me> |
| In reply to | #91613 |
On 03/08/2016 19:23, Les Cargill wrote: > jacobnavia wrote: >> WHO allocated this buffer? >> > > So in general, the buffer itself should tell you that. It could be a > property of the buffer, it could be implied by context, any of a number > of things. Who owns it? Declare an enum of "whos" and add a header to > buffers that tells you that. Knowing the owner might not help. The owner won't know if there's still a reference somewhere to the buffer. > I'm not nattering/complaining, it's just the many or most of the > projects I've worked on that needed dynamic objects, I spent > considerable time figuring out what was framed in what, how object > lifetimes worked, that sort of thing. Or you could leave such details to the GC instead. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-08-03 21:04 +0200 |
| Message-ID | <nntf83$8au$1@dont-email.me> |
| In reply to | #91614 |
Le 03/08/2016 à 20:27, BartC a écrit : > Or you could leave such details to the GC instead. EXACTLY!!!! I could also have designed the debugger better, I could also have written the front end better, I could have done many things in my life. It was really hard to make the debugger WORK at all. Then, the problems of having the debugger allocate a buffer to pass information to the front end (in another thread), then formatting that information, then keeping it current (at each LINE I have to change MANY displays) etc. Why spending time to figure out that kind of stuff if I can do it automatically??? I am not programming software like Mr Cargill where the sofwtare MUST work at all costs because maybe people's lives depend on that software. I have NEVER implied that a GC is a solution in THAT environment. But I just do not understand why he doesn't see MY side of things: WHY BOTHER WITH malloc/free ???
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2016-08-03 20:08 +0100 |
| Message-ID | <877fbxzn4f.fsf@gmail.com> |
| In reply to | #91617 |
jacobnavia <jacob@jacob.remcomp.fr> writes:
> Le 03/08/2016 à 20:27, BartC a écrit :
>> Or you could leave such details to the GC instead.
>
> EXACTLY!!!!
Couldn't agree more. GC isn't a panacea but for a GUI app like an IDE
where buffers are being passed around without any clear notion of
ownership - why would anyone want any other solution?[0]
There's a reason that standard C and C++ are no longer the first choice
GUI programming languages.
> WHY BOTHER WITH malloc/free ???
Yup.
[0] Reference counting could probably be made to work, but you're bound
to hit some circular references and have to worry about who has the
weak reference... Yuk.
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2016-08-03 16:09 -0500 |
| Message-ID | <nntm92$17d$1@dont-email.me> |
| In reply to | #91618 |
Gareth Owen wrote: > jacobnavia <jacob@jacob.remcomp.fr> writes: > >> Le 03/08/2016 à 20:27, BartC a écrit : >>> Or you could leave such details to the GC instead. >> >> EXACTLY!!!! > > Couldn't agree more. GC isn't a panacea but for a GUI app like an IDE > where buffers are being passed around without any clear notion of > ownership - why would anyone want any other solution?[0] > > There's a reason that standard C and C++ are no longer the first choice > GUI programming languages. > This. +several. >> WHY BOTHER WITH malloc/free ??? > > Yup. > > [0] Reference counting could probably be made to work, but you're bound > to hit some circular references and have to worry about who has the > weak reference... Yuk. > I tend to use Tcl/Tk a lot for GUIs a lot, and you still have objects that need to persist. But it's a nicely interpretive language, and there's not a lot of work in tracking these sorts of things. Plus, you can introspect screen objects - get a list of the children of windows, that sort of thing. -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2016-08-03 16:06 -0500 |
| Message-ID | <nntm3k$kn$1@dont-email.me> |
| In reply to | #91617 |
Jacob: Lest ye think I am picking on you, nothing could be further from the truth. Frankly, I realize I'm forced to sort of be ... thickheaded about this. Hopefully, that's not too unpleasant. Celebrate the diversity :) jacobnavia wrote: > Le 03/08/2016 à 20:27, BartC a écrit : >> Or you could leave such details to the GC instead. > > > EXACTLY!!!! > > I could also have designed the debugger better, I could also have > written the front end better, I could have done many things in my life. > But of course! :) > It was really hard to make the debugger WORK at all. Then, the problems > of having the debugger allocate a buffer to pass information to the > front end (in another thread), then formatting that information, then > keeping it current (at each LINE I have to change MANY displays) etc. > Yeah. And see, I immediately start thinking about how to build an "interface" for that. And that may be total overkill. But because my habits are "make an interface that can be independently verified", that's where I'd at least start. > Why spending time to figure out that kind of stuff if I can do it > automatically??? > I dunno - maybe it's completely not the point with something like that. > I am not programming software like Mr Cargill where the sofwtare MUST > work at all costs because maybe people's lives depend on that software. > Right! And I didn't mean that to come off like I'm somehow ... superior or anything. I imagine most things I've done are smaller footprint than that debugger. But some are not. And a lot of this is - I have to be accountable for these things, so making it formal ends up being the right approach. > I have NEVER implied that a GC is a solution in THAT environment. But I > just do not understand why he doesn't see MY side of things: > > WHY BOTHER WITH malloc/free ??? > > > So the best I can put it is: Why is it that not having to care actively in a design about object lifespan helps. And what surprised me is - I can't answer that directly. What we're up against is that I can't recall any cases I've run into where I think that GC would actually help. So without a concrete example ( and we'll only get so far down that road here ) I'm still scratching my head. This is really more of a protestation of ignorance on my part. -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-08-03 23:36 +0200 |
| Message-ID | <nnto5r$760$1@dont-email.me> |
| In reply to | #91623 |
Le 03/08/2016 à 23:06, Les Cargill a écrit : > So the best I can put it is: Why is it that not having to care actively > in a design about object lifespan helps. And what surprised me is - I > can't answer that directly. > The debugged program hits a breakpoint and windows sends me a message as the registered debugger. I read all that, then send it to the debugger thread in a newly allocated buffer. This is variable since if I hit an unknown breakpoint or if I have a crash at an unknown location the info is quite different than when I hit a regular breakpoint for hich I have debug info. The debugger thread receives a notification and a buffer to display, and sends the orders to the editor that activates the program text display, then passes that info (also in buffers) to the different windows at the bottom: stack display, auto display, locals display, whatever. To free something I have to free it in the thread it was allocated, so when a window closes (or needs to display different info) it needs to activate the debugger thread. But is the buffer replicated somewhere? Yeah, look it is a complex piece of software and the less things it has to manage the better. I haven't had any problems with the GC since ages, and I was able to write a DEBUGGER with just my mind since I am working alone on this. No team, like in your environment. > What we're up against is that I can't recall any cases I've run into > where I think that GC would actually help. Have you ever written GUI software? I mean not using a language like python or whatever but IN C? I have done that, and it is evry easy if you just use a GC! If not, well I would be interested in your general approach. You talk about interfaces, can you elaborate? Thread 1: Interrupt, inferior hits a breakpoint, windows sends me the IP address, some info about the breakpoint etc. I allocate a buffer and send it to the thread 2 Thread 2: Receives the buffer and sends it to the window controller in thread 3, the GUI, after having translated the IP address into a file, line and function context. It allocates a buffer and sends that info into thread 3 Thread 3 receives that info, sends the info to the editor that repositions the debuggers current line, resfreshes the text display, and updates all displays (stack, locals etc) I have to free those buffers but they were allocated in the debugger thread. Is anyone using that info still? Can I free it? In some cases that is evident (old info from the updated windows is no longer accessible, well unless you want to keep an history of values etc, what I do not do). But in other cases that is far more difficult. All this accounting takes code and effort. The GC does that for me. But how would you design that process? What interface/protocol would you use? This is an interesting discussion and I would be interested in discussing this here in comp.lang.c We do not exchange our technical knowledge here, and speak too much about religion, whatever. If you want you can start a new thread or go on in this one, as you like. And it is not urgent. Take your time, think about it, and send some message in the future.
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2016-08-03 19:44 -0500 |
| Message-ID | <nnu2rc$7s9$1@dont-email.me> |
| In reply to | #91625 |
jacobnavia wrote: > Le 03/08/2016 à 23:06, Les Cargill a écrit : > >> So the best I can put it is: Why is it that not having to care actively >> in a design about object lifespan helps. And what surprised me is - I >> can't answer that directly. >> > > > The debugged program hits a breakpoint and windows sends me a message as > the registered debugger. I read all that, then send it to the debugger > thread in a newly allocated buffer. This is variable since if I hit an > unknown breakpoint or if I have a crash at an unknown location the info > is quite different than when I hit a regular breakpoint for hich I have > debug info. > I think the critical thing here may be "Windows", because I've not done enough Win32 programming to know whether you can copy-from-and-discard the message at the point of receipt or not. I don't see it done much, but I suspect that has more to do with it being painful than bad practice. And even if you can, it might be pretty ugly. But my instinct is to map the Windows message onto a message common and specialized to the codebase, then pass that. And if I had chosen a more OO approach in the program, this might mean allocating/new()ing an object and passing references, or passing tokens and having a look up table. What that would afford me is to then have a mechanism in the object to determine when to delete the object, if not a callback that executes the destructor or ( or simply the destructor itself ). There are complications with this. But it affords accounting for what objects are outstanding. > The debugger thread receives a notification and a buffer to display, and > sends the orders to the editor that activates the program text display, > then passes that info (also in buffers) to the different windows at the > bottom: stack display, auto display, locals display, whatever. > > To free something I have to free it in the thread it was allocated, so > when a window closes (or needs to display different info) it needs to > activate the debugger thread. But is the buffer replicated somewhere? > Yes; that's part of the rationale of a state-object that belongs purely to the debugger. I feel most Windows event objects are really on loan to the program, and are not to be fooled with any more than you have to. And in cases where strong memory protection is in play, this is more conformant to those expectations. > Yeah, look it is a complex piece of software and the less things it has > to manage the better. I haven't had any problems with the GC since ages, > and I was able to write a DEBUGGER with just my mind since I am working > alone on this. No team, like in your environment. > >> What we're up against is that I can't recall any cases I've run into >> where I think that GC would actually help. > > Have you ever written GUI software? I mean not using a language like > python or whatever but IN C? > I have, but not too much. I mainly use a scripting language. :) The cases I have are pretty basic, and usually spend most of the "money" on a stack of some sort. For example, I wrote a "guitar tuner"/ analyzer[1] that uses Portaudio. The interactions with the Windows API are pretty limited. [1] it's a tuner that I use to design tempered tunings for steel guitar. It supports estimating the current temper of the guitar against Pythagorean, equal and various Just intonations. I then enter data into an application for a fancy tuner that has offsets. In this case, I don't have nearly the level of interaction with the Windows kernel that a breakpoint event represents. > I have done that, and it is evry easy if you just use a GC! > > If not, well I would be interested in your general approach. You talk > about interfaces, can you elaborate? > Unfortunately, the word "interface" gets overabused a lot. I mean: An interface can be expressed as an object which enables message passing. The methods/entry points are there for demuxing individual data elements out of the message. You could have a constructor do all the copying of the fields of a Windows message, then use those in the main GUI. This has to do with long, long habit of drawing message sequence charts to define use cases. > Thread 1: Interrupt, inferior hits a breakpoint, windows sends me the IP > address, some info about the breakpoint etc. I allocate a buffer and > send it to the thread 2 > > Thread 2: Receives the buffer and sends it to the window controller in > thread 3, the GUI, after having translated the IP address into a file, > line and function context. It allocates a buffer and sends that info > into thread 3 > > Thread 3 receives that info, sends the info to the editor that > repositions the debuggers current line, resfreshes the text display, and > updates all displays (stack, locals etc) > > I have to free those buffers but they were allocated in the debugger > thread. Is anyone using that info still? Can I free it? > Right. > In some cases that is evident (old info from the updated windows is no > longer accessible, well unless you want to keep an history of values > etc, what I do not do). But in other cases that is far more difficult. > Yeah, that begins to more closely approximate exactly what a GC algorithm would do. > All this accounting takes code and effort. The GC does that for me. > But how would you design that process? > > What interface/protocol would you use? > I'd have a "breakpoint" object that gets constructed from the Windows object. The Windows breakpoint message would then be delete/free-ed. This is somewhat less nasty than it sounds :) C++ is nice for this, but not required. All you need is a struct with a callback to the mapper, then references to fields. That way, it's *your* memory, and you know. Obviously there are a lot of way to solve a problem like this. > This is an interesting discussion and I would be interested in > discussing this here in comp.lang.c > > We do not exchange our technical knowledge here, and speak too much > about religion, whatever. > I know, right? :) > If you want you can start a new thread or go on in this one, as you like. > > And it is not urgent. Take your time, think about it, and send some > message in the future. > > -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-03 15:03 -0700 |
| Message-ID | <339f0d8a-c7a2-4f4f-ae00-1cec96327ece@googlegroups.com> |
| In reply to | #91623 |
On Wednesday, August 3, 2016 at 4:01:50 PM UTC-5, Les Cargill wrote: > What we're up against is that I can't recall any cases I've run into > where I think that GC would actually help. So without a concrete > example ( and we'll only get so far down that road here ) I'm still > scratching my head. Garbage collection is often the right paradigm for code which passes around immutable objects, since one can effectively copy an entire object simply by copying a pointer. If a compiler supplies enough metadata that a GC can identify references that are held in registers, that can eliminate the need for memory synchronization when a different threads independently pass around pointers to the same objects (if pointers to reference-counted objects are passed around in different threads independently, keeping the counts synchronized can be difficult). The biggest complication with trying to apply garbage collection only to immutable objects is that it's very common in platforms like .NET or Java for code to have an immutable type which holds a reference to an object of a mutable type but never exposes it to anything that could change it. The only way the mutable-type object can to be notified when it was no longer needed is if the wrapper receives such notification. Allowing the inner object to evaporate when the wrapper is no longer needed avoids the need for either to receive notification. Perhaps the biggest advantage of a system which uses GC references as a total replacement for pointers is that dangling references are literally impossible unless the GC is buggy or code uses unsafe pointers to jinx things. Even with objects that encapsulate resources and need to be disposed, such disposal will leave a reference to an identifiably-dead object rather than a dangling reference to storage that might get reused for some other purpose.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-08-04 19:17 -0700 |
| Message-ID | <kfnr3a4hsc9.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #91610 |
Les Cargill <lcargill99@comcast.com> writes: I'm responding here to the previous posting and also a couple others downthread. My intention is to address your comments generally rather than respond to individual points. However I will quote some small excerpts to establish a context. > So the best I can put it is: Why is it that not having to care > actively in a design about object lifespan helps. The point of relying on automatic collection is not avoid thinking about memory management altogether, but to make the thinking easier and more efficient. Let me outline a general thought process in terms that I think you will be able to relate to your usual design work. Not the same, but with enough points of contact so that you can see the relationship. In approaching the design (ie, of the putative example), do all the thinking you would normally do for the lifetime of primary objects. By "primary object" I mean an object that can be referred to essentially directly by the application's user, either through a stream interface (eg, command line) or through a graphical interface for a GUI-type application. In most cases primary objects will be registered in some way in one or more program-wide registries, indexed by a string or graphical location to be able to "name" the object. Usually primary objects stick around until some UI interaction "deletes" them, which results internally in the object being removed from whatever registries it was put in. Processing the "delete command" has to do the right thing, and is (for the first level of the object graph) manual memory management. Note that an important part of the design process is figuring out which objects are primary and which are not. We need to pay attention to what happens with primary objects, so it's important to know whether a given object falls into this category or not. For secondary objects, we don't have to think about what their lifetimes will be. A secondary object needs to stick around as long as there is some path to it from some primary object. When there are no such paths its memory may be reclaimed. (Fine point: a primary object that has been removed from all registries but happens to be referenced by another primary object (ie, that is still registered) can be thought of as a secondary object. In a sense "primary-ness" is not a property of the object itself but a property of what links are used to refer to it. Hopefully you can see what I'm getting at here without my going into more detail.) To "remove" a primary object, simply take its reference out of the registry in question. This can be done either by reducing the size of the registry or by zeroing the pointer in the registry that refers to the object. Note that this might or might not result in reclaiming the primary object's memory - if a reference to it is stored in another registry, or it's referred to indirectly by some other still-registered primary object, then it needs to stick around for those still-active access paths. The step of "removing" a primary object constitutes manual memory management. The garbage collector then takes care of any heaving lifting needed for reachability analysis, and the grunt work of returning unused object(s) to the free memory pool. Of course, it is possible to do all that with specialized code for each project. But from a development efficiency standpoint it seems better to write that code just once in the collector, so that what is needed in each project is just the tip of the memory management iceberg, with most of the iceberg shared by all the projects that need it. Something I wanted to mention but didn't work its way into the flow is how to deal with resources (eg, open files). Any resource that is needed normally will be given its own object. When a resource object is allocation, normally it will register a "finalization hook", a function that is called just before the object is about to be reclaimed. I think most collectors these days provide a way to associate finalization hooks with allocated objects, for exactly this purpose. One further note, about program ending. Because of how resource management is done, when a program is going to exit it needs to release all primary objects, to make sure that any resources still open get finalized. This step also constitutes manual management, but usually one that is very easy to supply - simply go through every registry and release any primary object still referred to. Disclaimer: in real applications things can be more complicated than the outline above. I haven't talked about weak references, caching, ephemerons, and other aspects that are relevant for a more complete treatment. However I think there is enough substance here to get an appreciation for the kinds of thought flow used. To me, using automatic reclamation (eg, garbage collection) is not a substitute for thinking about memory management but an enhancer. It lets me focus my mental energies (which sadly always seem to be in short supply) on the key aspects of the problem, and not spend them on the "administrative" more mechanical aspects. It also helps in another way in that the only kind of allocation bug that will manifest is a memory leak, which are much easier to debug than mysterious crashes (or worse). In writing a line of code to release a (thought to be unused) object, I never have to think about whether it might be too early to do that: if in fact the object is still needed for some other purpose, it will be kept around as long as it is. > So without a concrete example ( and we'll only get so far down > that road here ) I'm still scratching my head. Let me give a short example that may help with this. I won't go into too much detail, but maybe some light will shine through. In a recent newsgroup thread there was discussion about how to implement a text editor. One data structure that was mentioned is "ropes". Ropes provides a very nice foundation for a large scale text editor: they easily scale up to multi-gigabyte files, with multi-level undo, and copy/paste of large sections of text between multiple buffers, with common text being shared by all the different places that hold on to it. A problem with ropes is that the same qualities that make common text sharable also make it hard to tell which pieces of the data structure are still in use and which are "orphans". To make ropes work there needs to be code that does global reachability analysis. Basically, that boils down to having something like a mark/sweep garbage collector. Given that ropes need all of that mechanism anyway, it's easier to just put all the memory management under a single umbrella of a global garbage collector. > The competitors to 'C' these days are more on the line of Python > and/or Rust. They are. The thing is, in some cases all I want is GC. I don't want all the other fuzziness that comes along with switching to a Python-type language. Furthermore, as long as GC is available only in "fuzzy" languages people will keep thinking of GC as a "fuzzy" language feature. Part of the point of discussing GC in C is to dispel the myth that GC is inherently a fuzzy feature. (None of the above is meant to denigrate Python, or Rust, or any other similar language. The point is how they are perceived is not the same as how C is perceived.)
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2016-08-05 05:48 +0200 |
| Message-ID | <20160805054817.0af37f27@maxa-pc> |
| In reply to | #91697 |
On Thu, 04 Aug 2016 19:17:42 -0700 Tim Rentsch <txr@alumni.caltech.edu> wrote: > > Something I wanted to mention but didn't work its way into the > flow is how to deal with resources (eg, open files). Any > resource that is needed normally will be given its own object. > When a resource object is allocation, normally it will register > a "finalization hook", a function that is called just before > the object is about to be reclaimed. I think most collectors > these days provide a way to associate finalization hooks with > allocated objects, for exactly this purpose. Wrong. Finalizers are useless for resource management as conservative GC is non deterministic. Finalizers are only good for debugging purposes...
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-05 08:24 -0700 |
| Message-ID | <lninvfz1b1.fsf@kst-u.example.com> |
| In reply to | #91699 |
Melzzzzz <mel@zzzzz.com> writes:
> On Thu, 04 Aug 2016 19:17:42 -0700
> Tim Rentsch <txr@alumni.caltech.edu> wrote:
>> Something I wanted to mention but didn't work its way into the
>> flow is how to deal with resources (eg, open files). Any
>> resource that is needed normally will be given its own object.
>> When a resource object is allocation, normally it will register
>> a "finalization hook", a function that is called just before
>> the object is about to be reclaimed. I think most collectors
>> these days provide a way to associate finalization hooks with
>> allocated objects, for exactly this purpose.
>
> Wrong. Finalizers are useless for resource management as conservative GC
> is non deterministic. Finalizers are only good for debugging purposes...
I would imagine that non-deterministic finalization might still be
useful. For example, if you have an open file associated with some
object, closing that file *eventually* might be good enough.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2016-08-05 18:30 +0200 |
| Message-ID | <20160805183052.2284e4d3@maxa-pc> |
| In reply to | #91733 |
On Fri, 05 Aug 2016 08:24:18 -0700 Keith Thompson <kst-u@mib.org> wrote: > Melzzzzz <mel@zzzzz.com> writes: > > On Thu, 04 Aug 2016 19:17:42 -0700 > > Tim Rentsch <txr@alumni.caltech.edu> wrote: > >> Something I wanted to mention but didn't work its way into the > >> flow is how to deal with resources (eg, open files). Any > >> resource that is needed normally will be given its own object. > >> When a resource object is allocation, normally it will register > >> a "finalization hook", a function that is called just before > >> the object is about to be reclaimed. I think most collectors > >> these days provide a way to associate finalization hooks with > >> allocated objects, for exactly this purpose. > > > > Wrong. Finalizers are useless for resource management as > > conservative GC is non deterministic. Finalizers are only good for > > debugging purposes... > > I would imagine that non-deterministic finalization might still be > useful. For example, if you have an open file associated with some > object, closing that file *eventually* might be good enough. > Problem is that GC is not obliged to free all objects at all, let alone in specific order ;)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-05 10:34 -0700 |
| Message-ID | <ln1t23yva0.fsf@kst-u.example.com> |
| In reply to | #91741 |
Melzzzzz <mel@zzzzz.com> writes:
> On Fri, 05 Aug 2016 08:24:18 -0700
> Keith Thompson <kst-u@mib.org> wrote:
>> Melzzzzz <mel@zzzzz.com> writes:
>> > On Thu, 04 Aug 2016 19:17:42 -0700
>> > Tim Rentsch <txr@alumni.caltech.edu> wrote:
>> >> Something I wanted to mention but didn't work its way into the
>> >> flow is how to deal with resources (eg, open files). Any
>> >> resource that is needed normally will be given its own object.
>> >> When a resource object is allocation, normally it will register
>> >> a "finalization hook", a function that is called just before
>> >> the object is about to be reclaimed. I think most collectors
>> >> these days provide a way to associate finalization hooks with
>> >> allocated objects, for exactly this purpose.
>> >
>> > Wrong. Finalizers are useless for resource management as
>> > conservative GC is non deterministic. Finalizers are only good for
>> > debugging purposes...
>>
>> I would imagine that non-deterministic finalization might still be
>> useful. For example, if you have an open file associated with some
>> object, closing that file *eventually* might be good enough.
>
> Problem is that GC is not obliged to free all objects at all, let alone
> in specific order ;)
And if that's a problem, it's a problem.
If you're using GC, and it provides finalization hooks, *and* if
you have other resources (such as open files) such that you don't
care about the timing of freeing them any more than you care about
the timing of freeing memory, then the non-determinism won't be
a problem. Otherwise, it will.
My point is merely that your referring to such finalizers as
"useless" is an overstatement. There certainly are cases where
they're insufficient.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2016-08-05 20:50 +0200 |
| Message-ID | <20160805205019.0d130b83@maxa-pc> |
| In reply to | #91747 |
On Fri, 05 Aug 2016 10:34:31 -0700 Keith Thompson <kst-u@mib.org> wrote: > Melzzzzz <mel@zzzzz.com> writes: > > On Fri, 05 Aug 2016 08:24:18 -0700 > > Keith Thompson <kst-u@mib.org> wrote: > >> Melzzzzz <mel@zzzzz.com> writes: > >> > On Thu, 04 Aug 2016 19:17:42 -0700 > >> > Tim Rentsch <txr@alumni.caltech.edu> wrote: > >> >> Something I wanted to mention but didn't work its way into the > >> >> flow is how to deal with resources (eg, open files). Any > >> >> resource that is needed normally will be given its own object. > >> >> When a resource object is allocation, normally it will register > >> >> a "finalization hook", a function that is called just before > >> >> the object is about to be reclaimed. I think most collectors > >> >> these days provide a way to associate finalization hooks with > >> >> allocated objects, for exactly this purpose. > >> > > >> > Wrong. Finalizers are useless for resource management as > >> > conservative GC is non deterministic. Finalizers are only good > >> > for debugging purposes... > >> > >> I would imagine that non-deterministic finalization might still be > >> useful. For example, if you have an open file associated with some > >> object, closing that file *eventually* might be good enough. > > > > Problem is that GC is not obliged to free all objects at all, let > > alone in specific order ;) > > And if that's a problem, it's a problem. > > If you're using GC, and it provides finalization hooks, *and* if > you have other resources (such as open files) such that you don't > care about the timing of freeing them any more than you care about > the timing of freeing memory, then the non-determinism won't be > a problem. Otherwise, it will. > > My point is merely that your referring to such finalizers as > "useless" is an overstatement. There certainly are cases where > they're insufficient. > Well if you can live with that that finalizer is not guaranteed to run, I am ok ;)
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-08-05 15:39 -0700 |
| Message-ID | <kfnwpjuhmce.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #91699 |
Melzzzzz <mel@zzzzz.com> writes: > On Thu, 04 Aug 2016 19:17:42 -0700 > Tim Rentsch <txr@alumni.caltech.edu> wrote: > >> Something I wanted to mention but didn't work its way into the >> flow is how to deal with resources (eg, open files). Any >> resource that is needed normally will be given its own object. >> When a resource object is allocation, normally it will register >> a "finalization hook", a function that is called just before >> the object is about to be reclaimed. I think most collectors >> these days provide a way to associate finalization hooks with >> allocated objects, for exactly this purpose. > > Wrong. Finalizers are useless for resource management as conservative GC > is non deterministic. Finalizers are only good for debugging purposes... That is a gross overstatement. And obviously there are ways to mitigate the problem, especially in the context of program exit cleanup. In any case my commentary was meant as a broad brush outline about using GC generally, not specifically about conservative collectors. Even in that domain, how useful something is depends on what alternatives are available. I daresay a system based on a conservative collector would exhibit better memory use behavior than some browsers I run, which rely on manual memory management rather than GC or something similar.
[toc] | [prev] | [next] | [standalone]
Page 7 of 9 — ← Prev page 1 2 3 4 5 6 [7] 8 9 Next page →
Back to top | Article view | comp.lang.c
csiph-web