develooper Front page | perl.perl6.internals | Postings from September 2005

Re: GMC release

Thread Previous | Thread Next
From:
Andy Dougherty
Date:
September 1, 2005 11:34
Subject:
Re: GMC release
Message ID:
Pine.SOC.4.62.0509011345160.22818@maxwell.phys.lafayette.edu
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		doughera@lafayette.edu

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About