From: Archie Cobbs (archie@whistle.com)
Date: Tue Oct 20 1998 - 10:44:24 EDT
Godmar Back writes:
> Okay, after a bit more testing I checked it in.
> I still haven't tested object with more than 32 refs (or refs
> after the thirty-second slot) and I also haven't tested m68k and
> friends. Let me know what's breaking.
>
> The speed improvements for doing things like, say recompiling
> its own class libraries, are dramatic. For instance, on an elderly
> 200 MHz PPro/64MB, without any -m switches, the library compile
> spends 74 instead of 121 seconds in user land (out of a total
> run time of 106 vs. 150).
>
> When given the switches we normally give (-mx 64M -ms 8M),
> it spends 42 instead of 60 seconds in user land out of a total of
> 79 and 99.
Godmar,
Very cool! I'm glad to see the gc being sped up, it needs it :-)
> A second possible avenue for improvement is to get rid of the
> colocation of page headers and pages since this is prone to
> cache conflict misses.
This is what the FreeBSD malloc/free library does, and it has
helped performance there. If you're interested, check out the
source in /usr/src/lib/libc/stdlib/malloc.c.
Another possibility I've wondered about (this is complete
speculation)... It seems like some sort of 'imperfect reference
counting' could greatly improve GC speed and/or interactive response.
By this I mean each object has a reference count associated with
it, and the RC is guaranteed to be either accurate, or too high.
So if it goes to zero, you can always free the object. But otherwise,
you must wait for normal mark & sweep GC to free it.
One advantage of doing this is that we can improve it incrementally,
by adding precision to the reference count in discrete steps. That
is, once all assignments are modified to increment the reference
count, the 'unassignments' that decrement the count can be dealt
with in a lazy fashion.
For example, the first step might be to only catch cases of objects
that are created and forgotten without their reference ever being
copied, for example:
String s;
public int getValue() throws NumberFormatException {
return new Integer(s).intValue();
}
These could be detected at class loading time, etc.
Later, we could get to full reference incrementing/decrementing
for all assignments and method exit points, etc.
Seems like this would go a long way toward making the gc act more
incremental. At least, it would be an interesting experiment...
Godmar, has someone tried this before that you know of? That is,
mixing mark/sweep and reference counts? Did they get the best or
the worst of both worlds? :-)
-Archie
___________________________________________________________________________
Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:57:01 EDT