Precise GC (was Re: cannot build libjava/gnu/gcj/xlib/natClip.cc)

Wed Jan 3 17:05:00 GMT 2001

> > 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:
Examples: 
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
 collected.
Classloaders:
 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.
Cedric