RE: JvAttachCurrentThread doesn't seem to call GC_new_thread

["John Neil" <jneil at atrove dot com>]

I recently had a similar problem with a port I did of java to another RTOS.
In this case I found it easiest to modify the posix java thread
implementation to maintain a global list of all java threads, including
attached threads and then use this list for GC scanning in
GC_push_all_stacks.  This also restricts the GC scanning to only the Java
threads, which can be an advantage or a disadvantage depending on the
application.  Just a thought.

John


-----Original Message-----
From: java-owner@gcc.gnu.org [mailto:java-owner@gcc.gnu.org] On Behalf Of
Per Bothner
Sent: Tuesday, 27 January 2004 5:23 AM
To: java@gcc.gnu.org; hans_boehm@hp.com
Subject: JvAttachCurrentThread doesn't seem to call GC_new_thread

I got a bug report from a client about aborting with "Collecting from 
unknown thread", which is in GC_push_all_stacks in win32_threads.c. 
This was from a native thread that he called JvAttachCurrentThread on.

So I looked at the code trying to understand what should happen.  It 
looks to me that JvAttachCurrentThread needs to call GC_new_thread to 
register itself.

I also looks like GC_new_thread is only called by GC_thr_init and 
GC_start_routine.  GC_thr_init is called once when the GC system is 
initialized, and it only calls GC_new_thread once on the current thread. 
GC_start_routine is called when starting a new thread (in the pthread 
case by pthread_create).

It looks to me like we don't handle the case of a native thread that is 
not the initial thread.  This applies to both pthreads (Posix) and Win32.

Am I missing something?  Or is this a known limitation?  Would it be 
difficult to fix?  Obviously some locking is needed.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/