This is the mail archive of the
java-discuss@sourceware.cygnus.com
mailing list for the Java project.
Re: Projects
- To: Tom Tromey <tromey at cygnus dot com>
- Subject: Re: Projects
- From: "Jonathan P. Olson" <olson at mmsi dot com>
- Date: Thu, 4 May 2000 10:00:23 -0700
- Cc: Tom Tromey <tromey at cygnus dot com>, green at cygnus dot com, java-discuss at sourceware dot cygnus dot com
- References: <200004271348.GAA23627@fencer.cygnus.com> <0005040853430S.15141@jpo-laptop.mmsi.com> <200005041614.JAA20057@ferrule.cygnus.com>
On Thu, 04 May 2000, Tom Tromey wrote:
>Jon> Regarding precise and copying GCs, see my comments above. In a C
>Jon> or C++ environment I just don't see how they're justifyable.
>
>I think they still make sense. We don't have to solve the whole
>problem, because in general we aren't going to be allocated unions or
>weird C structures using the GC. We only have to solve the part of
>the problem relating to GCable objects -- i.e., Java objects.
>
>Tom
I disagree with the idea that only Java should get garbage collection.
Garbage collection makes most problems much simpler and makes many
problems tractable that are totally intractable without a collector. Garbage
collection eliminates most of the complex issues of tracking down memory
leaks and makes programs much more reliable. With CNI, there isn't really
a clear distinction between what is a C++ object and what is a Java object.
Similarly, a collector shouldn't distinguish between GCable languages and non
GCable ones.
Garbage collection isn't slow as most people who haven't used it think. Typical
run times for collecting a 2 megabyte heap on a 130 mhz embedded StrongARM run
about 20-30 milliseconds. With write barriers, this is all background time when
other threads are still executing.
--
Jon Olson, Modular Mining Systems
3289 E. Hemisphere Loop
Tucson, AZ 85706
olson@mmsi.com
Phone: (520)746-9127
Fax: (520)889-5790