status of gcj's boehm collector?

[Boehm, Hans]

> > 1) Use a software write barrier.  Insert instructions to keep track
> >    of heap writes.

> Ugh, so every time a pointer value on the heap is modified, a second
> memory access has to be performed to update the target page's dirty
> bit? That sounds *really* expensive.

 It's not free.  It's usually also not horrendously expensive, since pointer
writes to the heap are usually not that frequent.  Non-pointer writes don't
matter to the collector.

Dealing with system calls:

It probably wouldn't be that hard to not write protect pointerfree objects.
I will go ahead and do that when I find the time.

Note that if you fail to wrap a system call and it writes to protected
memory, the system call fails, possibly in a nonrecoverable way.  You
basically have to avoid that.

There are system calls other than read that share this problem.  The most
annoying one is probably ioctl, since it's not easy to predict where it's
going to write.

HotSpot vs. gcj performance:

If you allocate almost exclusively short-lived objects in a single thread, I
think it's very unlikely you will see full collections.  And the minor
collections are no doubt faster than gcj.  So your observations make sense
to me.

Prefetch:

I believe the AMD version of the prefetch instruction faults on a PII+.  The
PIII version appears to be a no-op on a PII.  I haven't tried the other
possible combinations.  Ideally we should compile in all 3 versions of the
marker (it's not that much code), and choose dynamically.  (The AMD version
doesn't seem to help much on a K6-2.  It may make more of a difference on an
Athlon.)

Hans