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]