Re: Object/Memory Management

On 2/24/02 10:23 PM, "Frank Mitchell" <[e-mail]> wrote:

>> 
>> 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?

In the context of the conversation, he clearly meant the latter.

>> 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.

Thanks for the update. I haven't done anything serious with Java in awhile.
This sounds like exactly what Borland was talking about. They were also
concerned, IIRC, that even where the the OSes VM is robust enough to support
large memory spaces, there is often a perceptible lag while the system
access the disk.

My personal take is that if I have to concern myself with memory management,
there are languages that have much better toolsets than Java has for doing
that.

>> 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.

Nor I. I'm inferring, perhaps over-inferring, from remarks on the Ruby Cocoa
page that Ruby Cocoa is more suitable for prototyping than for producing
commercial quality desktop apps. I took this to be more of a comment on the
nature of Ruby than on any implementation details of the Cocoa interface.
-- 
C++: The power, elegance and simplicity of a hand grenade.