This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
RE: threads and gc on SPARC/Solaris 2.8
- To: "'Jeff Sturm'" <jsturm at one-point dot com>, "Boehm, Hans" <hans_boehm at hp dot com>
- Subject: RE: threads and gc on SPARC/Solaris 2.8
- From: "Boehm, Hans" <hans_boehm at hp dot com>
- Date: Tue, 7 Aug 2001 15:34:20 -0700
- Cc: "'Andrew Haley'" <aph at cambridge dot redhat dot com>, java at gcc dot gnu dot org, "Hans-J. Boehm" <boehm at acm dot org>
This is actually fixed in a slightly different way in the GC 6.0 on my web
site. The right solution is probably to integrate that code.
The problem is that I haven't had a chance to learn enough about CVS to do
the right integration magic. I believe the current GC6.0 won't integrate
cleanly without some changes to libjava/boehm.cc. Those are currently in my
tree. If someone wants to volunteer to do the CVS magic, I'll be happy to
supply that patch.
Hans
> -----Original Message-----
> From: Jeff Sturm [mailto:jsturm@one-point.com]
> Sent: Tuesday, August 07, 2001 2:59 PM
> To: Boehm, Hans
> Cc: 'Andrew Haley'; java@gcc.gnu.org; Hans-J. Boehm
> Subject: RE: threads and gc on SPARC/Solaris 2.8
>
>
>
>
> On Wed, 27 Jun 2001, Boehm, Hans wrote:
> > The trunk has a bug, as does my version.
> GC_clear_stack_inner is called,
> > but not defined for SPARC + threads. It looks to me like
> removing the /* &&
> > !defined(THREADS) */ condition in mach_dep.c should fix the
> problem. I
> > think that was only a space optimization, which is now no
> longer correct.
> > I'll apply that fix to my version, but I'd appreciate it if
> someone with a
> > less modified tree could test it and check it in sooner than I will.
>
> It looks like nobody has fixed this on the trunk yet.
>
> I tried Hans's suggestion... gctest aborts on an "Illegal Instruction"
> trap. That may explain why the code was conditionalized in the first
> place.
>
> The faulting address is consistently the top of a VM page. Wild
> conjecture: GC_clear_stack_inner is entering a guard page,
> and the kernel
> handles the page fault. On attempting to emulate the store (can
> SPARC not restart the faulting instruction?) the kernel
> doesn't recognize
> the instruction format with a global register.
>
> The following seems to work. Does it look reasonable? I really don't
> know SPARC very well.
>
> Index: mach_dep.c
> ===================================================================
> RCS file: /cvs/gcc/gcc/boehm-gc/mach_dep.c,v
> retrieving revision 1.8
> diff -u -r1.8 mach_dep.c
> --- mach_dep.c 2001/05/21 08:35:13 1.8
> +++ mach_dep.c 2001/08/07 21:34:58
> @@ -511,7 +511,7 @@
> /* returns arg. Stack clearing is crucial on SPARC, so we
> supply */
> /* an assembly version that's more careful. Assumes limit
> is hotter */
> /* than sp, and limit is 8 byte aligned.
> */
> -#if defined(ASM_CLEAR_CODE) && !defined(THREADS)
> +#if defined(ASM_CLEAR_CODE)
> #ifndef SPARC
> --> fix it
> #endif
> @@ -540,6 +540,8 @@
> #else
> asm("mov %sp,%o2"); /* Save sp */
> asm("add %sp,-8,%o3"); /* p = sp-8 */
> + asm("st %o1,[%o1]"); /* force stack growth
> if needed */
> + asm("and %o3,-8,%o3"); /* force doubleword alignment */
> asm("clr %g1"); /* [g0,g1] = 0 */
> asm("add %o1,-0x60,%sp"); /* Move sp out of the way, */
> /* so that traps still work. */
>
>