Projects

Tue May 9 10:52:00 GMT 2000

[None of this is relevant to the original discussion, but I couldn't
resist.]
[Corey Minyard wrote:]
> But if we could null
> everything when done, then manual memory management would be easy :-).

I've heard this claim frequently, but I disagree. Nulling pointers is
fundamentally easier and safer than manual memory management. There are two
reasons for that:
1) It's a more local decision. I only need to declare when I'm done with a
particular pointer, which may be one of many to a particular object. In
some cases, its trivial to tell when I'm done with a pointer, but I need
extra synchronization to tell when I'm done with the object it points to.
See http://www.hpl.hp.com/personal/Hans_Boehm/gc/example.html
2) When I get it wrong, I get a null pointer exception directing me at the
erroneously nulled pointer. When I get manual memory management wrong, I
often get a crash deep in unrelated code.
> Ok, you are right. Although GCJ currently uses the metadata for this,
> the performance does stink. I've worked on a different method than
> the bit array; I implemented something that scanned the metadata for a
> class the first time it was collected and created a table of ranges to
> scan and stuck that in the vtable for the class. It uses the table
> after that. I'm not sure if the bit array is better performance-wise,
> but it wasn't ready when I was doing this and it is limited to 128
> byte objects (unless something has changed recently).

It hasn't, though it changes to about 500 bytes with a 64 bit machine.
Larger objects can be handled with a custom mark procedure that interprets
longer bitmaps. My theory is that the added overhead will be amortized over
the larger object, and won't be noticable. Whether this is correct remains
to be seen.

>> > However, I believe that collecting a 1 GB heap is an entirely
> > different problem than collecting a 1 MB heap. I hate to see the
> > application that actually has an entire 1GB of heap space active at
> > once.
>> It's pretty scary. It makes the class overhead pretty trivial, I'd
> gladly trade memory for performance.
>I would actually guess that an Itanium or Alpha box with 2GB physical memory
and a 1 GB live heap should work OK, at least if we can get the incremental
GC mode going with gcj. 30MB live on a machine 30 times slower was
tolerable, and I don't see any reason this shouldn't scale if you have 64
bit pointers. With 32 bit pointers, I would guess that many applications
will still be OK, but some won't. There's an old SP&E paper by Wentworth
that discusses conservative garbage collection with effectively 16 bit
pointers and a 64K heap, i.e. with every bit pattern a valid pointer.
Hans