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

Ivan Maidanski ivmai at mail.ru
Sun Apr 14 07:17:09 PDT 2013


 Hi Dave,

About GC_thread_suspend/resume, please look into these posts:
*  http://article.gmane.org/gmane.comp.programming.garbage-collection.boehmgc/5469
* http://article.gmane.org/gmane.comp.programming.garbage-collection.boehmgc/3988
*  http://article.gmane.org/gmane.comp.programming.garbage-collection.boehmgc/2989

Regards,
Ivan

Wed, 10 Apr 2013, 9:24 +01:00 from Andrew Haley <aph at redhat.com>:
>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.
>
>
>_______________________________________________
>Gc mailing list
>Gc at linux.hpl.hp.com
>http://www.hpl.hp.com/hosted/linux/mail-archives/gc/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://napali.hpl.hp.com/pipermail/gc/attachments/20130414/b8fb3b1f/attachment.htm


More information about the Gc mailing list