[Gc] RE: Solaris/X86 GC issues (was /bin/sh portability issues ...)
hans.boehm at hp.com
Fri Jul 7 15:49:40 PDT 2006
Sorry about the typo in the previous subject. Reposting to make
> -----Original Message-----
> From: java-patches-owner at gcc.gnu.org
> [mailto:java-patches-owner at gcc.gnu.org] On Behalf Of Boehm, Hans
> Sent: Friday, July 07, 2006 3:45 PM
> To: Roger Sayle; Rainer Orth
> Cc: java-patches at gcc.gnu.org; gcc-patches at gcc.gnu.org;
> gc at linux.hpl.hp.com
> Subject: Solaris/X96 GC issues (was /bin/sh portability issues ...)
> 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.
> > -----Original Message-----
> > From: java-patches-owner at gcc.gnu.org
> > [mailto:java-patches-owner at gcc.gnu.org] On Behalf Of Roger Sayle
> > Sent: Friday, July 07, 2006 6:25 AM
> > To: Rainer Orth
> > Cc: java-patches at gcc.gnu.org; gcc-patches at 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 at 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:
> > >
> > > 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
> > 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
> > --
More information about the Gc