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
>