[Gc] Re: Usage of _Jv_AttachCurrentThread, _Jv_AttachCurrentThreadAsDaemon, _Jv_DetachCurrentThread.

Andrew Haley aph at redhat.com
Wed Apr 10 01:24:37 PDT 2013

On 04/09/2013 07:20 PM, Dave Korn wrote:
> [ Please Cc: me in replies, I'm not subbed to java@ list. ]
>     Hi Java list,
>   Under what conditions would the thread attach/detach functions (from
> libjava/java/lang/natThread.cc) listed in the title of this email be called?
>   My motivation for asking this is because they call the _Jv_GCAttachThread
> and _Jv_GCDetachThread thread functions in libjava/boehm.cc.  These functions
> key off the existence of pthread_getattr_np on the host to call the boehm-gc
> functions GC_register_my_thread and GC_unregister_my_thread like so:
>> void
>> _Jv_GCAttachThread ()
>> {
>>   // The registration interface is only defined on posixy systems and
>>   // only actually works if pthread_getattr_np is defined.
>>   // FIXME: until gc7 it is simpler to disable this on solaris.
>>   GC_register_my_thread ();
>> #endif
>> }
>> void
>> _Jv_GCDetachThread ()
>> {
>>   GC_unregister_my_thread ();
>> #endif
>> }
>   Recent versions of the Cygwin DLL have added pthread_getattr_np, which
> triggers the #if'd code to compile, but the win32/Cygwin thread support code
> in boehm-gc doesn't implement these functions, so libjava fails to link.
>   I could fix this by either adding a !defined(GC_WIN32_THREADS) in the same
> way as Solaris disables these functions, or I could add an implementation of
> the functions in boehm-gc for Cygwin, which is posixy and pthread-based.
>   In order to decide which approach to take, I'd like to understand the
> purpose of registering/deregistering an existing thread as opposed to catching
> it on startup and exit via the pthread_create/pthread_join/thread_start
> wrappers that already exist, hence my question about when and why the
> functions in natThread.cc (which are the only users of the boehm.cc functions)
> would be invoked.

People may choose to call Java from an already-running program.  In that
case, the thread already exists, and catching it on startup is impossible.

>   Also on the same topic, would there be any value added by providing Cygwin
> implementations of GC_suspend_thread, GC_resume_thread and
> GC_is_thread_suspended, which are called from _Jv_SuspendThread,
> _JV_ResumeThread, _JV_IsThreadSuspended in boehm.cc and currently #if'd out by
> a test on GC_WIN32_THREADS?

I'll leave that to the GC list.


More information about the Gc mailing list