Re: Learning Cocoa (OT!: Small Language Rant)
Re: Learning Cocoa (OT!: Small Language Rant)
- Subject: Re: Learning Cocoa (OT!: Small Language Rant)
- From: Jonathan Stimmel <email@hidden>
- Date: Mon, 16 Jul 2001 16:05:43 -0700
- Mail-followup-to: Jonathan Stimmel <email@hidden>, Cocoa-Dev <email@hidden>
On Mon, Jul 16, 2001 at 02:32:05PM -0700, John C. Randolph wrote:
>
Last I heard, most Java VM's could still halt your program at random
>
intervals for a GC cycle. Has any Java environment started running the
>
GC in its own thread, yet?
The garbage collector is run in its own thread (at least in 1.2 and 1.3);
the problem is that the garbage collector needs a certain level of
control over the heap to do its job, so it may block other threads
while running. I *think* the 1.2 garbage collector (Sun's JVMs) is
asynchronous, while the 1.3 garbage collector *is* synchronous (but
it uses a generational algorithm that is much more efficient at
handling short-lived objects). In the latter case, yes your program's
threads will block periodically during garbage collection, but that's
just part of life as a multi-threaded process on a preemptive OS
(what's a few ms compared to that CPU-intensive process Joe User has
been running almost daily for the past month?).
>
Apple's got a GC that was developed for ScriptX, that is very good about
>
remaining unobtrusive. You could tell it (for example) to go and
>
collect until it gets 100K, or collect for 20 milliseconds, etc.
You can tune the java garbage collector (again, sun's JVMs), though
the parameters are naturally different from the ones you describe.
Under normal circumstances, the Java garbage collector is unobtrusive;
if it is severely interrupting a program's flow of execution then the
program (a) is allocating many more objects than it needs, (b) doesn't
have enough memory, or (c) shouldn't have been written in Java (e.g.,
a realtime app that needs to do something at exactly 20ms intervals).
The only time I've found the Java garbage collector to be "obtrusive"
was while performance tuning an application that was burning through
memory at a ridiculous rate (~30M/s). Under conditions such as those,
it doesn't it really matter whether it does 100 20ms runs or one 2s run;
the problem here is not the garbage collector, though, it's the memory
usage (which, for the record was easily located and fixed =).
Anyway, this is starting to sound like "my gc is better than yours",
which was not my intent. I've grown to like Java, many people don't,
ymmv...