[Gc] gc6.8, etc.

Boehm, Hans hans.boehm at hp.com
Wed Jul 12 17:41:59 PDT 2006


I decided to do a small amount of testing, and release the current gc6.X
tree as 6.8.  It really only has a couple of additional ports and some
small bug fixes relative to 6.7.

I had hoped to package up a new gc7.0 version as well, but it still
seems to have some problems with the dynamic library version on Windows.
I still hope to do that, but it will be at least a day or two.  I will
call that one 7.0alpha7 to distinguish it from the CVS versions.  I hope
that it will be reasonably stable, MUCH more so than 7.0alpha5.  It has
passed tests on various Linux(X86, IA64, X86-64, arm) and HP/UX
platforms, MacOS/ppc, FreeBSD/X86, and Solaris/SPARC.

There will only be a 6.9 if I get one or more critical bug fixes.  I am
no longer planning on including any new features or ports in 6.X.  Thus
if you submit such patches, patches against 7.0, ideally cvs head, are
greatly preferred.

Hans

> -----Original Message-----
> From: java-patches-owner at gcc.gnu.org 
> [mailto:java-patches-owner at gcc.gnu.org] On Behalf Of Rainer Orth
> Sent: Monday, July 10, 2006 5:22 AM
> To: Boehm, Hans
> Cc: Roger Sayle; java-patches at gcc.gnu.org; 
> gcc-patches at gcc.gnu.org; gc at napali.hpl.hp.com
> Subject: Re: Solaris/X96 GC issues (was /bin/sh portability 
> issues ...)
> 
> Hans,
> 
> > I checked Rainer's patch into the 7.0 tree, and added it to 
> my current
> > 6.8 tree.  Thanks.
> 
> great, thanks.
> 
> > That doesn't help with the Studio 11 cc problems that 
> Rainer reported 
> > earlier.  Someone with access to a suitable machine will 
> have to track 
> > those down.  The next step is to identify which objects are getting 
> > prematurely collected and why.  It would be useful to see 
> whether the 
> > offending list is referenced by an automatic or static pointer.  In 
> > either case, it is also worth checking that 
> > GC_with_callee_saves_pushed ends up calling getcontext(), as it 
> > should.  If it is a static pointer, and getcontext() is called 
> > correctly, I would next check that roots are being registered 
> > correctly, and the offending pointer is in a root segment.  Setting 
> > the GC_DUMP_REGULARLY environment variable prints roots on 
> a regular basis.
> > 
> > It is possible that the studio 11 issue also affects gcc, but just 
> > happened to not be exercised.
> 
> I'll start investigating this once I find some time.
> 
> > Slightly longer term, I'm not sure about the right path.  I don't 
> > really have enough cycles to work on 7.0, so I don't expect 
> to spend 
> > time on 6.8, except for relatively small and critical patches.  If 
> > someone can generate a 6.8 patch to make Solaris/X86 work, I'm 
> > certainly fine with just putting it into gcc.  I suspect it 
> would be 
> > big enough to be problematic.
> 
> Could you please provide a snapshot of 6.8 so I can test it 
> on Solaris/SPARC and Solaris/x86, try the integration into 
> GCC and see if it works?  Depending on the amount of changes 
> since 6.6, it might be acceptable for 4.2.  At the very 
> least, I'd like to get my patch for 64-bit
> Solaris/x86 support into 4.2 so it at least compiles out of the box.
> 
> > Overall, my vote would be for
> > 
> > 1) Making 7.0 work reliably on Solaris/X86.  (I have been testing 
> > occasionally on Solaris/SPARC, and it seems OK there.)
> > 2) Merging 7.0 into 4.3 early in that cycle.  My 
> expectation is that 
> > that would generate some breakage, mostly on less common 
> platforms.  
> > But on platforms like Linux, I think 7.0 is actually now 
> fairly stable.
> 
> That's probably the best course for 4.3, but not an option for 4.2.
> 
> 	Rainer
> 
> --------------------------------------------------------------
> ---------------
> Rainer Orth, Faculty of Technology, Bielefeld University
> 



More information about the Gc mailing list