From: Frank Mitchell Date: 2002-02-25T14:23:40+09:00 Subject: Re: Object/Memory Management Chris Gehlker wrote: > > On 2/23/02 5:15 PM, "Dave Thomas" wrote: > > > One last thought. Many (the majority?) of server-side web applications > > are currently being written in the COBOL of the New Millennium, Java. > > And Java uses garbage collection to dispose of objects. Seems to work > > fine for these applications. C# (and the clr) use garbage collection > > too. It seems to be with us to stay. > > But Dave, Java's GC notoriously sucks. I know from personal experience > that it sucked up to 1.1.8. [...] > > Later I heard that GC got better in Java 2. I had a chance to talk to one > of the JBuilder programmers about whether they were relying on it. He > said, "We do all our own memory management in JBuilder." How do they do that? Do they have their own JVM? Or do they simply mean they watch their memory allocations, and recycle objects manually? > The hasn't kept Java from becoming, as you say, the COBOL of the New > Millennium, but it sure kept Corel from succeeding with their Java office > suite. Java seems to be stuck in the middleware space, where it does > pretty well. Java 2 memory management is great ... as long as you have 2MB or more to start with. An ex-boss and Java hater was apalled that a fairly small server program consumed 2MB; there's simply no way to make Java 1.3 use less in its heap, and 1.4 is apparently worse. I've also seen problems with their "incremental" GC not being fast enough for a high-enough rate of garbage creation, leading to the process being pegged at its maximum heap size (and throwing an OutOfMemory eventually). As you say, Sun is aiming more at the server/middleware space, so the Sun JVM sucks for desktop apps with reasonable memory footprints ... never mind short-running command-line apps. Dunno about IBM's. Unfortunately, there are no other major JVM vendors; none of the freeware JVMs I've tried have been ready for prime time. > Now I've been going under the assumption that Ruby was good where Java is > Ok and would probably be inappropriate where Java is not so good. I make > the same assumption about C#. > > Am I way off base here? Automatic memory management has no inherent problems outside of hard real time or extremely memory-constrained environments, as far as I know. For a sufficiently sophisticated GC algorithm that matches the language or environment, automatic memory management can do as well or better than manual memory management. One can't judge all GC by Java's performance. Having said that, GC can get tricky to get right, and even trickier to optimize. I don't know the specifics of Ruby's GC, apart from it using mark-sweep with no copying or compaction. Maybe others can tell of specific weaknesses or pathological behaviors they've seen; I haven't done any heavy lifting in Ruby yet. -- Frank Mitchell (frankm@bayarea.net) "As an experimental psychologist I have been trained not to believe anything unless it can be demonstrated in the laboratory on rats or sophomores." -- Steven Pinker