This is the mail archive of the
mailing list for the Java project.
Re: Precise GC (was Re: cannot build libjava/gnu/gcj/xlib/natClip.cc)
- To: "Boehm, Hans" <hans_boehm at hp dot com>
- Subject: Re: Precise GC (was Re: cannot build libjava/gnu/gcj/xlib/natClip.cc)
- From: Cedric Berger <cedric at wireless-networks dot com>
- Date: Wed, 03 Jan 2001 17:06:07 -0800
- CC: jeff dot sturm at commerceone dot com, tromey at redhat dot com, Bryce McKinlay <bryce at albatross dot co dot nz>, Per Bothner <per at bothner dot com>, java-discuss at sources dot redhat dot com
- References: <140D21516EC2D3119EE700902787664401E3A7EC@hplex1.hpl.hp.com>
> > Fragmentation append with C code too, but you can workaround it by
> > 1) preallocating/recycling most of the big objects.
> > 2) keeping for example a 20% margin on the heap, and testing
> > extensively.
> It seems to me that with anything like a 20% margin, you're clearly relying
> on statistics.
Yes, I rely on statistics, but I do extensive testing. Testing for
fragmentation is easier than testing for pointer misidentification.
> Assuming you avoid certain brittle data structures (see
> http://www.hpl.hp.com/personal/Hans_Boehm/gc/bounds.html ), a false
> reference costs you one copy of your largest data structure, in the worst
> case, i.e. up to a factor of 2. Since you can get multiple false
This is really difficult to avoid theses data structures.
I really like the collections API, and use it extensively, like many
java2 programs. I just read today that Tomcat use HashMap of ArraySet
to store its parameters. what will append if the HashMap get falsely
referenced when I reload the parametres?
What makes that even worse is that Java use a lot of cyclic references
all over the place:
AWT/Swing: each component track both its parent and children.
When you destroy a frame, *any* false reference on any component
or part of component will prevent the entire stuff to be garbage
Classloader load classes and keep track of them, and each class
has a references back to its classloader.
if, at some point, you want to unload a module (say a Web
Application with tomcat), you get rid of the classloader and its
live object. But *any* false reference on either the classloader or
any class will prevent the whole tree to be garbage collected.
And so on...
This is *much* worse than what you suggest.
Sure, this will mainly affect long-running applications like
servers or embedded systems.