JvAttachCurrentThread doesn't seem to call GC_new_thread

Wed Jan 28 01:37:00 GMT 2004

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/