Usage of _Jv_AttachCurrentThread, _Jv_AttachCurrentThreadAsDaemon, _Jv_DetachCurrentThread.

Usage of _Jv_AttachCurrentThread, _Jv_AttachCurrentThreadAsDaemon, _Jv_DetachCurrentThread.

[Dave Korn]

[ 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.
> #if defined(HAVE_PTHREAD_GETATTR_NP) && !defined(GC_SOLARIS_THREADS)
>   GC_register_my_thread ();
> #endif
> }
> 
> void
> _Jv_GCDetachThread ()
> {
> #if defined(HAVE_PTHREAD_GETATTR_NP) && !defined(GC_SOLARIS_THREADS)
>   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.

  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?

    cheers,
      DaveK

Re: Usage of _Jv_AttachCurrentThread, _Jv_AttachCurrentThreadAsDaemon, _Jv_DetachCurrentThread.

[Andrew Haley]

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.
>> #if defined(HAVE_PTHREAD_GETATTR_NP) && !defined(GC_SOLARIS_THREADS)
>>   GC_register_my_thread ();
>> #endif
>> }
>>
>> void
>> _Jv_GCDetachThread ()
>> {
>> #if defined(HAVE_PTHREAD_GETATTR_NP) && !defined(GC_SOLARIS_THREADS)
>>   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.

Andrew.

Re: Usage of _Jv_AttachCurrentThread, _Jv_AttachCurrentThreadAsDaemon, _Jv_DetachCurrentThread.

[Bryce McKinlay]

On Tue, Apr 9, 2013 at 7:20 PM, Dave Korn <dave.korn.cygwin@gmail.com> wrote:

>   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.

As Andrew said, these are used by the JNI (& CNI) "invocation API",
which allows calling into Java code from a non-Java app.

It might be worth checking if newer versions of the GC already have
improvements here for Cygwin. libgcj's copy of boehm-gc is very old
and we really ought to update it!

>   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?

Well, I don't think anything in libgcj really uses these. They might
be useful as part of a debugging interface.

Bryce

Re: Usage of _Jv_AttachCurrentThread, _Jv_AttachCurrentThreadAsDaemon, _Jv_DetachCurrentThread.

[Dave Korn]

On 10/04/2013 10:34, Bryce McKinlay wrote:
> On Tue, Apr 9, 2013 at 7:20 PM, Dave Korn <dave.korn.cygwin@gmail.com> wrote:
> 
>>   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.
> 
> As Andrew said, these are used by the JNI (& CNI) "invocation API",
> which allows calling into Java code from a non-Java app.
> 
> It might be worth checking if newer versions of the GC already have
> improvements here for Cygwin. libgcj's copy of boehm-gc is very old
> and we really ought to update it!

  Yes indeed!  It turns out that upstream has implemented them since 7.0alpha2
(now at 7.3alpha4).

  Upstream now includes a new support library, libatomic_ops, that is licensed
under a combination of GPLv2 and a custom "MIT-style" licence.  Is that likely
to be any problem?

>>   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?
> 
> Well, I don't think anything in libgcj really uses these. They might
> be useful as part of a debugging interface.

  Good to know, thanks to both of you for the information.

    cheers,
      DaveK

RE: Usage of _Jv_AttachCurrentThread, _Jv_AttachCurrentThreadAsDaemon, _Jv_DetachCurrentThread.

[Boehm, Hans]

>   Upstream now includes a new support library, libatomic_ops, that is
> licensed under a combination of GPLv2 and a custom "MIT-style" licence.  Is
> that likely to be any problem?
> 
libatomic_ops turns out to have mostly been a useful evolutionary step on the way to C11/C++11 atomics.  If this is an issue, it should now be fairly easy, at least in the context of a recent gcc, to replace it with the latter.

The licensing was intended not to be a problem.  The GPLv2 pieces are either higher-level pieces not be needed at all by gcc, or are only tests for the library.  The atomics library itself is covered by the MIT-style license.  But, as I said, I think it's no longer critical.

Hans