tag:blogger.com,1999:blog-7028181408582795486.post2652174325692349900..comments2024-01-15T16:06:19.332+13:00Comments on Coding with the enemy: Garbage collection in Delphi Win 32: Why and how to do itSeanhttp://www.blogger.com/profile/09419639577416328173noreply@blogger.comBlogger20125tag:blogger.com,1999:blog-7028181408582795486.post-28595055504251520342015-01-04T05:53:32.140+13:002015-01-04T05:53:32.140+13:00Hello,
check GarbageDisposerReviews.com for all y...Hello,<br /><br />check <b>GarbageDisposerReviews.com</b> for all your garbage disposal related stuffs.<br /><br />Thanks<br />Anonymoushttps://www.blogger.com/profile/12401356210699626197noreply@blogger.comtag:blogger.com,1999:blog-7028181408582795486.post-9686088934652986532010-11-21T15:53:08.866+13:002010-11-21T15:53:08.866+13:00@anon, I only use delphi for maintenance now, I h...@anon, I only use delphi for maintenance now, I have moved to c# for all my new stuff. I have no idea if gc will ever come to delphi.Seanhttps://www.blogger.com/profile/09419639577416328173noreply@blogger.comtag:blogger.com,1999:blog-7028181408582795486.post-32774119016324060952010-11-20T20:38:56.314+13:002010-11-20T20:38:56.314+13:00Hi Sean,
Any news about gc?Hi Sean,<br />Any news about gc?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7028181408582795486.post-78703479799488957222008-01-26T14:48:00.000+13:002008-01-26T14:48:00.000+13:00Fernando, Flick me an email at sean @ sourceitsof...Fernando, <BR/><BR/>Flick me an email at sean @ sourceitsoftware .com<BR/>and I'll send it to you.<BR/><BR/>SeanSeanhttps://www.blogger.com/profile/09419639577416328173noreply@blogger.comtag:blogger.com,1999:blog-7028181408582795486.post-61019972440061120842008-01-25T22:44:00.000+13:002008-01-25T22:44:00.000+13:00Hi Sean,OK, will you post it here? I'll keep an ey...Hi Sean,<BR/><BR/>OK, will you post it here? I'll keep an eye on your blog until then. Thanks!<BR/><BR/>FernandoAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-7028181408582795486.post-46016876229887977082008-01-23T07:25:00.000+13:002008-01-23T07:25:00.000+13:00I changed it to use TmemoryManagerEx, and changed ...I changed it to use TmemoryManagerEx, and changed the allocation routines so that large (> 2mg) allocations are handled differently.<BR/><BR/>I am quite happy to share the code, I just need to clean it up a bit.Seanhttps://www.blogger.com/profile/09419639577416328173noreply@blogger.comtag:blogger.com,1999:blog-7028181408582795486.post-34735839163998294672008-01-23T05:00:00.000+13:002008-01-23T05:00:00.000+13:00Hi Sean,What modifications did you make to the ori...Hi Sean,<BR/><BR/>What modifications did you make to the original package? Are you willing to share the code?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7028181408582795486.post-55224904358518399012008-01-22T21:09:00.000+13:002008-01-22T21:09:00.000+13:00Craig.I am happy to agree with your latest comment...Craig.<BR/><BR/>I am happy to agree with your latest comments. The GC discussion has now moved into measurement territory, which is IMO a big step up.<BR/><BR/>Kind regards<BR/>CalebCaleb Hattinghhttps://www.blogger.com/profile/03530357670954941582noreply@blogger.comtag:blogger.com,1999:blog-7028181408582795486.post-91160959416693583562008-01-22T05:28:00.000+13:002008-01-22T05:28:00.000+13:00I personally find arguments over whether garbage c...I personally find arguments over whether garbage collection is "faster" or "slower" to be rather missing the point, kind of like saying that one shouldn't use Ruby because it's "slow." Please note that I have not made any such arguments about GC speed myself. Ruby is indeed generally slower than many compiled languages, but people use it anyway, in part because they find that they can write correct code quickly in that language. The slowest possible application is one which doesn't run at all, because you never finished it. Choosing a framework based solely on the theoretical maximum performance of the code you can write is, generally speaking, premature optimization, especially if you must sacrifice program completeness or correctness to get there.<BR/><BR/>I don't think that Sean is categorically claiming that garbage collection will be generally faster than manual memory management. I do think that he's saying that it doesn't have to be "slow," and that he has some basis in reality for saying this (there are, for example, real-time garbage collectors), in response to a barrage of myths and FUD from people who never use it, notably, the .non-tech thread.<BR/><BR/>To me, the choice of using garbage collection or not using garbage collection is completely dictated by the environment I'm working in. When I write .NET or Haskell code, I use garbage collection. When I write Delphi/Win32 code I don't. But I do miss the features, notably functional programming, that garbage collection allows when I work without it.Craighttps://www.blogger.com/profile/02430615130349705538noreply@blogger.comtag:blogger.com,1999:blog-7028181408582795486.post-42251574048438660322008-01-22T05:12:00.000+13:002008-01-22T05:12:00.000+13:00CraigWe're doing that cyclic argument thingy that ...Craig<BR/><BR/>We're doing that cyclic argument thingy that has become so passe in online forums. Let me state my views more clearly, and perhaps we might find common ground:<BR/><BR/>1. A GC is a great idea. It can certainly help ease memory management and accounting issues. But *don't* claim using a GC is faster than not without at least some *proof*. (Sean has now done this, which is excellent follow-up).<BR/><BR/>2. Be careful claiming GC is faster than manual when the performance of pretty much every high-profile client-side GCed app is poor (dexplore a good example). It may not be the GC (could be JIT, or even something else), but having it present by association with such languages doesn't help without *proof*.<BR/><BR/>3. Disabling Together in the Delphi IDE before the recent December update dramatically helped with IDE memory footprint and stability. This does not mean Together/.NET is fully responsible. There are certainly other non-GC leaks in other places. Nobody said there were not. It doesn't have to be either/or. Also, it was more likely that it was programmer error in using the .NET components, rather than a direct consequence of the GC alone. But this is my point: using a GC, there are just a different set of memory issues to think about when using a GC. Otherwise things can still go wrong. The claim is made that these issues are "fewer" than with manual memory allocation. That's a nice claim :)<BR/><BR/>4. When awesome, responsive client-side apps using GC start showing up, the strength of the arguments required for supporting GC as "better" than manual (in some sense) will quickly decrease. <BR/><BR/>5. Using FastMM with Delphi32 today makes finding memory leaks very easy. Using this, one can find most memory leaks in typical applications. I can't speak for other scenarios, but in my own applications I have used FastMM to fix memory leaks till they are leak-free. Using a GC *only* for the sake of memory issues is, in my opinion (and it is really just a personal opinion, I can't prove or justify it to you) not enough. If it also brings a speed benefit (remains to be seen) then we can start talking. <BR/><BR/>I don't think we're very far apart. We differ in the respect that I want proof about GC-related claims. I am not anti-GC as you seem to infer. I use python a lot, which has a GC (and fabulous syntax).Caleb Hattinghhttps://www.blogger.com/profile/03530357670954941582noreply@blogger.comtag:blogger.com,1999:blog-7028181408582795486.post-85502237303447261202008-01-19T03:50:00.000+13:002008-01-19T03:50:00.000+13:00Caleb, regarding Delphi, don't miss the forest for...Caleb, regarding Delphi, don't miss the forest for the trees: you can completely remove all use of the .NET framework from the Delphi IDE, and the editor still leaks on large files. This is provably true. Hence, attributing the leaks generally to garbage collection, and specifically to circular references is demonstrably wrong.<BR/><BR/>Incomplete code coverage during testing is not a "contrived situation." It is the rule, rather than the exception, unless you specifically test for coverage. Even with testing it's <I>quite</I> difficult to achieve 100% coverage on non-trivial applications. Moreover, if you're seriously going to argue that allocations which aren't cleaned up until the app shuts down are "contrived situations" and hence don't count in a discussion of leaks, then you've just "proven" the point that GC prevents all leaks, which I don't happen to believe, but go ahead and make it if that's what you think. <BR/><BR/>We could talk about dexplore leaking, and I could talk about a Win32 app that leaks, and what would that prove regarding Sean's points? Nothing whatsoever, AFAICS. <BR/>Sean never argued that GC eliminated leaks. He said that it reduces them, and that it allows programming idioms which are difficult-to-impossible without it, the latter a point that anti-GC types studiously avoid addressing. <BR/><BR/>Want real functional programming or LINQ-like comprehensions without GC? Good luck with that. When you train yourself not to do things which can't be done without GC, then perhaps GC seems less appealing. But it doesn't make functional programming a bad idea; it just means that you've closed yourself to doing it.Craighttps://www.blogger.com/profile/02430615130349705538noreply@blogger.comtag:blogger.com,1999:blog-7028181408582795486.post-70869799059007090602008-01-18T23:39:00.000+13:002008-01-18T23:39:00.000+13:00Craig###Don't let superstition and inexperience bl...Craig<BR/><BR/>###Don't let superstition and inexperience blind you to the advantages of GC or the limitations of manual memory management.<BR/><BR/>Excuse me? Ad-hominem arguments are only supposed to start after the first backwards and forwards post cycle.<BR/><BR/>###Caleb, you made up the bit about the Delphi IDE leaking due to garbage collection and circular references. <BR/><BR/>No. But I'll concede it may have been references that didn't go out of scope like they were expected to, because of a programming bug. Are you on the Delphi beta-test team?<BR/><BR/>###I'll remind you that the editor is Win32 code and isn't garbage collected, ...<BR/><BR/>You sound so sure, and yet some code insight features used in the editor, like error insight, apparently use .NET (accoring to Chris Hesik).<BR/><BR/>### even with Together disabled. <BR/><BR/>Why even mention this, if .NET GC is so wonderful? By the way, do you ever notice dexplore.exe eating crazy amounts of RAM? I do.<BR/><BR/>###Without having the Delphi source code, we can only guess as to which bit of code leaks the worst. <BR/><BR/>The delta bits between Delphi 7 and D2005 are highly suspect. I believe those were largely .NET related.<BR/><BR/>###The .NET GC, which is used in Delphi, isn't affected by circular references, which was Sean's point. <BR/><BR/>Fair enough, you are correct. I used the term circular references, but I misspoke, as indicated above. I can't remember the details of the December Update fix, but it was some kind of lingering-reference bug inside .NET code. Apologies.<BR/><BR/>###FastMM is indeed very nice, but you're also simply wrong to assert that FastMM guarantees that your apps don't leak. <BR/><BR/>Yes, ok. It is still possible in the range of contrived situations you point out. So what? I maintain that using FastMM gives you at least as much protection for memory related problems as using a GC does, and probably more.<BR/><BR/>Based on the few implementations of .NET code I have seen, and the high incidence of memory-related problems (Together, dexplore, ATI CCC) I am not convinced that GC platforms are better than manual memory management platforms "just by default". <BR/><BR/>AFAIAK, python uses a GC in order to manage duck-typing overhead and cleanup more efficiently, not to specifically prevent memory-leak bugs. And I've seen the python GC also blow up a few times under semi pathological conditions (particulary when JITing with psyco). <BR/><BR/>But what do I know, I'm blinded by superstition and inexperience :)<BR/><BR/>CalebCaleb Hattinghhttps://www.blogger.com/profile/03530357670954941582noreply@blogger.comtag:blogger.com,1999:blog-7028181408582795486.post-32816936617697550262008-01-18T21:43:00.000+13:002008-01-18T21:43:00.000+13:001. GC would be great even to support cross-platfor...1. GC would be great even to support cross-platform (Win32/.NET) single-code applications.<BR/><BR/>2. It would be great to have an options to either use or not use GC at the class and/or field/parameter level.<BR/><BR/>3. You can already use interfaces that are already references-counted if GC is very important in some particular case.<BR/><BR/>4. GC applications can be slower and can be faster. If you use interactive application then GC at idle time makes this app actually more responsive. If it's server app which is never idle than you get increased memory use and slowdown.<BR/><BR/>5. Being the almost the only (?) language supporing both native and managed platforms Delphi has a good opportunity to address different needs. Just leave it to a programme r to decide which paradigm to use in each particular case.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7028181408582795486.post-52213731716742155402008-01-18T05:52:00.000+13:002008-01-18T05:52:00.000+13:00Caleb, you made up the bit about the Delphi IDE le...Caleb, you made up the bit about the Delphi IDE leaking due to garbage collection and circular references. I'll remind you that the editor is Win32 code and isn't garbage collected, and the editor has been one of the worst memory hogs in recent times, even with Together disabled. Without having the Delphi source code, we can only guess as to which bit of code leaks the worst. The .NET GC, which is used in Delphi, isn't affected by circular references, which was Sean's point. <BR/><BR/>FastMM is indeed very nice, but you're also simply wrong to assert that FastMM guarantees that your apps don't leak. First, FastMM can only identify things which are in covered code. If your testing doesn't hit an area of code with a leak, then FastMM won't identify it. FastMM doesn't do coverage analysis at all, so you have no way of determining whether or not your app leaks at shutdown conclusively with FastMM alone. Second, FastMM can only conclusively identify things which are never released at all, as opposed to things which are freed much too late. Garbage collectors do this, too, but with or without the GC it's still argably a "leak" to forget to release something which should be released in milliseconds, even if it ends up being freed (e.g., via ownership) when the app shuts down. <BR/><BR/>Don't let superstition and inexperience blind you to the advantages of GC or the limitations of manual memory management.Craighttps://www.blogger.com/profile/02430615130349705538noreply@blogger.comtag:blogger.com,1999:blog-7028181408582795486.post-37727245884509146962008-01-17T22:20:00.000+13:002008-01-17T22:20:00.000+13:00###"There's also a problem with objects referencin...###"There's also a problem with objects referencing each other which prevents the items releasing": Not with any recent garbage collector.<BR/><BR/>This is the reason the Delphi IDE swells to over a gigabyte of RAM usage - some internal object references in the .NET part of the IDE referred to each other. (This might have been fixed, I haven't noticed it recently) This could mean that it was coded badly, but then it follows that using a GC doesn't automatically make memory-leak-type problems go away. Worse, for this example, the *expectation* that unused references would be freed let the problem slip through.<BR/><BR/><BR/>### "It's inefficient, it slow, and its unacceptable.": Again, not with any recent GC. In many cases a GC app is faster than non-gced.<BR/><BR/>You make the claim, but fail to provide any evidence. Just like every other blog post making the same claim. In the compiler shootout, GC languages do ok speed-wise, but they are certainly not faster. In addition, my user experience of every single .NET or Java application I have used was that it was slower, especially on startup. Perhaps you could cite even a single example I could look at that would support the claim?<BR/><BR/>### Strings, dynamic arrays and interfaces are already garbage collected in Delphi , and virtually everything is in Delphi.net.<BR/><BR/>Yes, and records too. They are also much slower to work with if they themselves contain lifetime-managed items (but that may only be because of how they are implemented). <BR/><BR/>###It is still possible to leak memory, but much harder.<BR/><BR/>True, but as you should know, Delphi Win32+FastMM FullDebugMode makes it impossible to leak memory and not know about it. There is no excuse today for releasing a Delphi Win32 app with memory leaks, because they are so easy to detect and trace.<BR/><BR/>###The result was about 4% fewer lines of code.<BR/><BR/>If you use python, that could become 40%, so what's your point? Interestingly, python also uses a GC, but tends to be slow compared to Java and .NET because it uses no JIT by default.<BR/><BR/>###In a non gc language, you end up with a number of idioms and practices to guard against memory leaks.<BR/><BR/>Agreed. It is not nice that concerns over the underlying machine should affect programming style.<BR/><BR/>###However most Delphi memory managers request large chucks of memory from windows and then parcel it out to the app on request, so this disadvantage is largely theoretical.<BR/><BR/>No evidence given. Not even a link. Shame on you :)<BR/><BR/>### Speed: A well written and tuned garbage collector can be faster than manual allocation. <BR/><BR/>Evidence?<BR/><BR/>###http://digitalmars.com/d/garbage.html<BR/><BR/>It's a nice page, with lots of compelling, strongly-worded arguments, but alas no *evidence*. Pages like this:<BR/>http://www.griffinlair.com/cs/<BR/>don't seem to support their claims either.Caleb Hattinghhttps://www.blogger.com/profile/03530357670954941582noreply@blogger.comtag:blogger.com,1999:blog-7028181408582795486.post-86399730793359220932008-01-17T19:12:00.000+13:002008-01-17T19:12:00.000+13:00Mark,Have a look at http://digitalmars.com/d/garba...Mark,<BR/><BR/>Have a look at <BR/>http://digitalmars.com/d/garbage.html re gc and speed. It's a not peer reviewed academic article, but the guys do write compilers so there is a chance they know what they are talking about about.Seanhttps://www.blogger.com/profile/09419639577416328173noreply@blogger.comtag:blogger.com,1999:blog-7028181408582795486.post-5041770397134083942008-01-17T16:47:00.000+13:002008-01-17T16:47:00.000+13:00A small correction: The Delphi GC you link was sub...A small correction: The Delphi GC you link was submitted by Barry <B>Kelly</B>, who, since he submitted that, has been hired by CodeGear to work on the Delphi compiler. <BR/><BR/>The issue I have with people who equate GCs with sloppiness is that they have trained themselves to write only code which is compatible with manual memory management. You give a couple of examples, like functions which return objects and LINQ, but I'll add another big one: Functional programming in general. Functional languages are nearly <I>always</I> garbage collected, and it's quite clear why when you look at how they work. <BR/><BR/>Another issue is the expressiveness of the language. I'd like to deal with memory management explicitly when it is critical to my application, and not deal with it when it isn't. The idea is similar to lazy evaluation: By reducing your code to an expression of only <I>what</I> the code needs to do instead of <I>how</I> the code should do it, you allow the OS to make adjustments for the current hardware. This has already paid off significantly with PLINQ; one can make code exploit multi-CPU hardware with trivial changes to query expressions, instead of coding in thread pools, etc., which might require a ground-up rewrite.<BR/><BR/>For those who have never really learned the GC way of working, be careful about discounting what you don't understand. Like dynamic languages, GC has its ups and downs. It's not the right solution for all problems. But even its advocates seem to mostly push GC as a means of catching programmer errors in memory management, whereas the most important error in question, in my opinion, is <I>a closed mind</I>.Craighttps://www.blogger.com/profile/02430615130349705538noreply@blogger.comtag:blogger.com,1999:blog-7028181408582795486.post-65697573265241185812008-01-17T15:50:00.000+13:002008-01-17T15:50:00.000+13:00We will just have to disagree on many of your poin...We will just have to disagree on many of your points. You say that those who oppose gc can't cite specific cases, but then neither do you in this blog.<BR/><BR/>However, there is one point where I can't believe you are serious. Its where you make the assertion that a well written gc (is there such a thing?) is faster at deallocating memory than doing it manually... Really? Prove it.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7028181408582795486.post-29512485633390582942008-01-17T15:44:00.000+13:002008-01-17T15:44:00.000+13:00Sean,I'm sure you'll get that old saw that garbage...Sean,<BR/><BR/>I'm sure you'll get that old saw that garbage collection is for sloppy or inexperienced programmers, and I agree with that to some degree. Generally, it seems to me that successful Delphi programmers are probably pretty good, so they don't see the need. But I've run across slop before that was way too object-oriented, such that the author would wrap objects around the smallest datapoints. This is a recipe for hard-to-find leaks, and that exactly was the end-result. Thanks to Fastmem I was able to find some holes (but not all of them). A good GC would have saved me a lot of time here.<BR/><BR/>OTOH, languages that do more work for you (like duck typing) are a lot more deserving of a GC than Delphi is. I think most of the work that a Delphi GC would do is just clean up messes. But, I'd be happy to have it if it really saved some typing of try/finally.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7028181408582795486.post-63039129508826121322008-01-17T15:42:00.000+13:002008-01-17T15:42:00.000+13:00Sean,I'm sure you'll get that old saw that garbage...Sean,<BR/><BR/>I'm sure you'll get that old saw that garbage collection is for sloppy or inexperienced programmers, and I agree with that to some degree. Generally, it seems to me that successful Delphi programmers are probably pretty good, so they don't see the need. But I've run across slop before that was way too object-oriented, such that the author would wrap objects around the smallest datapoints. This is a recipe for hard-to-find leaks, and that exactly was the end-result. Thanks to Fastmem I was able to find some holes (but not all of them). A good GC would have saved me a lot of time here.<BR/><BR/>OTOH, languages that do more work for you (like duck typing) are a lot more deserving of a GC than Delphi is. I think most of the work that a Delphi GC would do is just clean up messes. But, I'd be happy to have it if it really saved some typing of try/finally.Anonymousnoreply@blogger.com