On Thu, 1 Sep 2005, Nattfodd wrote:
> Andy Dougherty wrote:
>
> > On Thu, 1 Sep 2005, Nattfodd wrote:
> >
> >
> > > today is the deadline for the google summer of code projects, and it's
> > > time
> > > anyway for a "release" of GMC.
> > > GMC is a generational garbage collector for parrot that allows copying of
> > > objects and thus copying GC schemes.
> > >
> >
> > Thanks for submitting this. I also appreciated the extensive comments in
> > the source (even if I didn't actually read most of them :-).
> >
> >
> > > svn co https://svn.perl.org/parrot/branches/gmc
> > >
> >
> > First, I needed the following simple patch to MANIFEST
> >
> > --- gmc/MANIFEST Thu Sep 1 09:12:48 2005
> > +++ parrot-andy/MANIFEST Thu Sep 1 10:19:20 2005
> > @@ -1639,6 +1639,7 @@
> > src/exec_start.c []
> > src/exit.c []
> > src/extend.c []
> > +src/gc_gmc.c []
> > src/gc_gms.c []
> > src/gc_ims.c []
> > src/generic_register.c []
> >
> >
> > After that, with Sparc/Solaris 8, with Sun's CC, I got a core dump
> > even on a simple
> >
> > ./miniparrot -h
> >
> If only miniparrot is called without arguments, the GC is never called, which
> narrows much the place to look for the bug...
I get the same crash without arguments, i.e., with a plain ./miniparrot.
> > Overall, I wonder if it's an alignment issue, since SPARC tends to be
> > much more sensitve to that than x86. I haven't looked deeply at the
> > code at all, but do you do anything special to ensure that the blocks
> > of memory you are moving around maintain their aligment?
> >
> Actually, no, I don't ensure it in any way... I don't know exactly what
> alignment constraints are, but here, a whole memory zone is allocated (in
> gc_gmc_gen_init() called from gc_gmc_more_bodies()). Then all the content of
> the old memory zone is memcpyed to the content of the new one in a single
> instruction (src/gc_gmc.c:871). Both old and new have exactly the same size.
> So I imagine that if the start of the two zones are aligned in the same way
> (does the fact that both are obtained from malloc guaranty that ?), then so
> does every object in it...
On SPARC, doubles should be aligned on 8-byte boundaries. The compiler
normally handles this correctly and automatically (e.g. by adding padding
within structures as necessary, etc.) but if you're playing memory games
and casting everything to (char *) and manipulating addresses, then the
compiler obeys your commands and does what you request.
If indeed you're just copying one contiguous block from one malloc()-ed
spot to another, and the size is obtained from sizeof(), then you should
be fine. Malloc() is supposed to return memory suitably aligned for any
use.
> But I begin to have serious doubts about objects being correctly aligned in
> the first place. I'll try to see if I can make sure of alignment tonight...
>
> On the other hand, I think compaction can break alignment, as bodies can have
> variable size (even if it's not yet the case here).
> However, the output you give seems to indicate that this is not corruption, as
> pointers all seem to be valid (I had a lot of errors here earlier, but it was
> always with either ptr or hdr->pmc being set to NULL).
I initially suspected alignment because with a optimized compile, I get
signal BUS (invalid address alignment) in gc_gmc_more_bodies at
0x7c278
> I added a GMC_NO_GC_RUN symbol that you can define if you want to disable it
> completely (to be sure that compaction is not responsible).
Defining that (on an optimized compile) changes the specific type of
crash:
signal SEGV (no mapping at the fault address) in gc_gmc_more_bodies at
0x7c258
One last thought about alignment: In macros such as the following one
in include/parrot/smallobject.h
#define Gmc_PMC_hdr_get_BODY(pmc_hdr)
((PMC_BODY*)((char*)(pmc_hdr) + sizeof(Gc_gmc_hdr)))
you have to be very careful about alignment and padding issues. That
is, if you have a struct p { int a, double b }, you can't assume that
'b' is located at &p + sizeof(a). There might be padding. Instead,
use the offsetof() macro.
--
Andy Dougherty [EMAIL PROTECTED]
