RE: Supporting pthreads in libjava on Tru64 UNIX

["Boehm, Hans" <hans_boehm at hp dot com>]

Sorry about the delayed response, and thanks for the patches.

I'll hold off on applying them to my tree, since there are clearly still some outstanding issues with a few pieces.  If you decide not to pursue this further, let me know, and I'll put it on my list to fix this.

There is general GC debugging advice at http://www.hpl.hp.com/personal/Hans_Boehm/gc/debugging.html, but
that's not very relevant here.  Here's my guess as to what's going wrong with your code:

> ===================================================================
> RCS file: include/private/RCS/gc_locks.h,v
> retrieving revision 1.1
> diff -up -r1.1 include/private/gc_locks.h
> --- include/private/gc_locks.h	2003/05/31 00:54:20	1.1
> +++ include/private/gc_locks.h	2003/07/04 16:17:31
> @@ -182,9 +182,13 @@
>                               "       beq %0,3f\n"
>                               "       mb\n"
>                               "2:\n"
> +#       ifdef __ELF__
>                               ".section .text2,\"ax\"\n"
> +#       endif
>                               "3:     br 1b\n"
> +#       ifdef __ELF__
>                               ".previous"
> +#       endif
>                               :"=&r" (temp), "=m" (*addr), 
> "=&r" (oldvalue)
>                               :"Ir" (1), "m" (*addr)
>  			     :"memory");
> ===================================================================
Disclaimer: I don't think I wrote this code, and I don't currently have access to a machine on which I can test this, though that's no doubt fixable.  Having said that:

I would have expected this to result in the symptoms you're observing.  I believe the intent here is that the

beq	%0,3f

instruction branches to a different segment, located elsewhere at a higher address, that reads

3:	br 1b

i.e. the first branch branches to the second, which branches back to the beginning of the loop.  But it's important that the "br 1b" not be executed if you fall through the bottom of the code.

I believe that replacing the 

beq	%0,3f

by

beq	%0,1b

and just deleting the code in section text2 should work.  But my guess is that the original code is written in the more baroque way is that the processor predicts the branch correctly by default (forward branch predicted not taken, backward branch is probably predicted as taken in the absence of real information).  So this patch will involve a mild performance penalty and probably shouldn't be used unconditionally, i.e. on Linux.

> RCS file: RCS/pthread_support.c,v
> retrieving revision 1.1
> diff -up -r1.1 pthread_support.c
> --- pthread_support.c	2003/06/18 23:10:38	1.1
> +++ pthread_support.c	2003/07/04 16:07:55
> @@ -139,6 +139,12 @@
>  #   endif
>  #   undef pthread_join
>  #   undef pthread_detach
> +#   ifndef _PTHREAD_USE_PTDNAM_
> +/* Restore the original mangled names on Tru64 UNIX.  */
> +#     define pthread_create __pthread_create
> +#     define pthread_join __pthread_join
> +#     define pthread_detach __pthread_detach
> +#   endif
>  #endif
>  
>  void GC_thr_init();
> 
What's _PTHREAD_USE_PTDNAM_ ?  Shouldn't this also be testing explicitly that we're on Tru64 (still called OSF1 here)?


Hans