Re: [boehm-gc] Define HBLKSIZE to 4096 for MIPS

[Richard Sandiford <rsandifo at nildram dot co dot uk>]

Thanks for looking at the patch.

Hans Boehm <Hans.Boehm@hp.com> writes:
> It also looks like a good idea to me.  The collector assumes that
> the page size is a multipe of HBLKSIZE, so we should probably
> change this on some other platforms with configurable page sizes
> as well.
>
> I missed the first part of this discussion, and can't immediately find
> it.  Did this result in failures outside the collector test itself?
> I would have expected this to affect only incremental GC, which
> I thought was still hard to use with gcj?

I'm afraid the current discussion is all there is.  Once I realised
that HBLKSIZE was bigger than the page size, that it wasn't supposed
to be, and that "fixing" it made the bugs go away, I assumed that that
was the real problem, and that I was seeing an expected failure mode.

As it turns out, I think it was the real problem, and that the
tests were failing simply because the mmap()ed heap areas weren't
HBLKSIZE-aligned.  This obviously breaks hblk lookup.

E.g. in FileHandleGcTest, the first mmap()ed address was 0x55587a3000
and the others were all contiguous with that.  The second half of each
hblk was then mapped to the same bottom_index entry -- and thus the
same header -- as the first half of the following hblk.  We had a
GC_DS_PER_OBJECT hblk B following a non-GC_DS_PER_OBJECT hblk A,
and we tried to mark an object in the second half of A as though
it had a type descriptor, leading to an invalid access.  (Of course,
other weird things happened too, like when we tried to recreate a hblk
address from a bottom_index key, and get something other than the
hblk's true address.)

David, I've now applied the patch.  Sorry again for the delay.

Richard