public inbox for java@gcc.gnu.org
 help / color / mirror / Atom feed
* Usage of _Jv_AttachCurrentThread, _Jv_AttachCurrentThreadAsDaemon, _Jv_DetachCurrentThread.
@ 2013-04-09 18:17 Dave Korn
  2013-04-10  8:24 ` Andrew Haley
  2013-04-10  9:34 ` Bryce McKinlay
  0 siblings, 2 replies; 5+ messages in thread
From: Dave Korn @ 2013-04-09 18:17 UTC (permalink / raw)
  To: GCC Java

[ 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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Usage of _Jv_AttachCurrentThread, _Jv_AttachCurrentThreadAsDaemon, _Jv_DetachCurrentThread.
  2013-04-09 18:17 Usage of _Jv_AttachCurrentThread, _Jv_AttachCurrentThreadAsDaemon, _Jv_DetachCurrentThread Dave Korn
@ 2013-04-10  8:24 ` Andrew Haley
  2013-04-10  9:34 ` Bryce McKinlay
  1 sibling, 0 replies; 5+ messages in thread
From: Andrew Haley @ 2013-04-10  8:24 UTC (permalink / raw)
  To: Dave Korn; +Cc: GCC Java

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.


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Usage of _Jv_AttachCurrentThread, _Jv_AttachCurrentThreadAsDaemon, _Jv_DetachCurrentThread.
  2013-04-09 18:17 Usage of _Jv_AttachCurrentThread, _Jv_AttachCurrentThreadAsDaemon, _Jv_DetachCurrentThread Dave Korn
  2013-04-10  8:24 ` Andrew Haley
@ 2013-04-10  9:34 ` Bryce McKinlay
  2013-04-10 23:18   ` Dave Korn
  1 sibling, 1 reply; 5+ messages in thread
From: Bryce McKinlay @ 2013-04-10  9:34 UTC (permalink / raw)
  To: Dave Korn; +Cc: GCC Java

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Usage of _Jv_AttachCurrentThread, _Jv_AttachCurrentThreadAsDaemon, _Jv_DetachCurrentThread.
  2013-04-10  9:34 ` Bryce McKinlay
@ 2013-04-10 23:18   ` Dave Korn
  2013-04-11  5:03     ` Boehm, Hans
  0 siblings, 1 reply; 5+ messages in thread
From: Dave Korn @ 2013-04-10 23:18 UTC (permalink / raw)
  To: GCC Java; +Cc: Bryce McKinlay, Andrew Haley

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* RE: Usage of _Jv_AttachCurrentThread, _Jv_AttachCurrentThreadAsDaemon, _Jv_DetachCurrentThread.
  2013-04-10 23:18   ` Dave Korn
@ 2013-04-11  5:03     ` Boehm, Hans
  0 siblings, 0 replies; 5+ messages in thread
From: Boehm, Hans @ 2013-04-11  5:03 UTC (permalink / raw)
  To: Dave Korn, GCC Java; +Cc: Bryce McKinlay, Andrew Haley

>   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

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2013-04-11  5:03 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-04-09 18:17 Usage of _Jv_AttachCurrentThread, _Jv_AttachCurrentThreadAsDaemon, _Jv_DetachCurrentThread Dave Korn
2013-04-10  8:24 ` Andrew Haley
2013-04-10  9:34 ` Bryce McKinlay
2013-04-10 23:18   ` Dave Korn
2013-04-11  5:03     ` Boehm, Hans

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).