Solaris/X96 GC issues (was /bin/sh portability issues ...)

[Boehm, Hans]

I checked Rainer's patch into the 7.0 tree, and added it to my current
6.8 tree.  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 think the GC_register_has_static_roots_callback issue was
libjava-specific, since I hadn't gotten around to putting the patch that
introduced it into the CVS tree.  (I just corrected that).  It should be
defined in dyn_load.c, though it would be undefined if DYNAMIC_LOADING
somehow didn't get defined in gcconfig.h.  (That's probably not the way
things should work.  I made it a noop in that case for 7.0.  But the
real problem is probably in your gcconfig.h.)

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.

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.

Hans

> -----Original Message-----
> From: java-patches-owner@gcc.gnu.org 
> [mailto:java-patches-owner@gcc.gnu.org] On Behalf Of Roger Sayle
> Sent: Friday, July 07, 2006 6:25 AM
> To: Rainer Orth
> Cc: java-patches@gcc.gnu.org; gcc-patches@gcc.gnu.org
> Subject: Re: [JAVA] /bin/sh portability issues in 
> scripts/check_jni_methods.sh
> 
> 
> On 7 Jul 2006, Rainer Orth wrote:
> > Roger Sayle <roger@eyesopen.com> writes:
> > > terminating with a hard error, and enables libjava to reach the 
> > > application linking steps at the end of the build (which 
> suffer from 
> > > boehmgc issues that I may not have resolved correctly).
> >
> > This is probably PR boehm-gc/21942.
> > I've recently sent a new message about this to the boehm-gc list:
> > 
> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/2006-June/001334.h
> > tml
> 
> Cool!  Yes, this exactly the issue and your patch above is 
> nearly identical to the one I have in my tree to allow the 
> build to reach libjava.  Unfortunately, I'm seeing a 
> unresolved symbol reference to 
> GC_register_has_static_roots_callback from libgcj.so when 
> attempting to link jv-convert, so I wasn't sure if it was my 
> X86_64/SUNOS5 changes in boehmgc/include/private/gcconfig.h 
> that were at fault, or another latent problem in the libjava 
> build system.
> 
> Anyway, thanks again for pointing out that you're on top of 
> this particular issue (one less thing for me to worry about). 
>  Hopefully, Hans will comment soon.  I did check the upstream 
> sources to see if it was just an import of the latest boehmgc 
> that was required.
> 
> Thanks again for addressing this.
> 
> Roger
> --
> 
>