Re: timetable change on mingw-libgcj

[Jonathan Olson <olson at mmsi dot com>]

Actually, MacOS X handles thread suspension and resumption much better
than conventional thread implementations, since each pthread maps to a 
single
kernel mach thread.  For example, to suspend a thread, you can do the 
following:

	mach_port_t mthread = pthread_mach_thread_np(pthr);
	mach_msg_type_number_t threadStateCount = PPC_THREAD_STATE_COUNT;
	struct ppc_thread_state threadState;
	if( thread_suspend(mthread) != KERN_SUCCESS
		|| thread_get_state(mthread, PPC_THREAD_STATE,
					(natural_t *)&threadState,
					&threadStateCount) != KERN_SUCCESS )
		return -1;
	setStackTop((void *)&threadState.rl);

Note that in this example, the thread being suspended doesn't need to 
catch
any signals and doesn't experience indeterminate side effects like 
waking up
from a system call with an error.  Also, the collector doesn't have to 
block waiting
for the thread to catch the signal and suspend itself.

Note that the second call to thread_get_state() is used to get the 
thread's top of
stack in `threadState.rl' so that the collector can properly scan the 
thread stack.

On Monday, December 17, 2001, at 05:18  PM, Boehm, Hans wrote:

> I agree that's not good.
>
> How are MacOSX threads implemented?  Do they map directly to kernel 
> threads?
> Is there a way to stop a thread other than by sending it a signal?
>
> Pthread_kill seems to be used by _Jv_ThreadInterrupt and the GC.  Last I
> checked, Thread.interrupt() seemed broken in enough VMs that you might 
> get
> away without if for a while.
>
> The collector needs pthread_kill to stop all non-GC threads during a 
> GC.  If
> there's an alternate way to suspend threads, that might work, though 
> it's
> ugly.  (Solaris_threads.c uses this approach, though it's complicated 
> there
> by the fact that it actually suspends lwps, i.e. kernel-level 
> threads.)  You
> need to able to stop threads in such a way that:
>
> a) You can wait for them to actually stop.  (Just sending a signal 
> without
> waiting for an acknowledgement from the handler is probably not 
> sufficient.)
>
> b) You can somehow get at enough of each thread's state that the 
> collector
> can find pointers in registers and on the stack.  The Solaris 
> implementation
> relies on the fact that you can fairly easily find dirty stack pages,
> something that's probably not true for most other operating systems.  
> This
> is needed since there is no easy way to retrieve the stack pointer 
> values.
>
> If someone has connections at Apple, it might be worth asking what they 
> do
> in their JVM to stop threads for the collector.  Unfortunately, they may
> compile in code so that threads can voluntarily stop when requested.  
> This
> is a bit problematic if a gcj thread is in a long running 
> compute-intensive
> piece of CNI code.
>
> Hans
>
>> -----Original Message-----
>> From: Adam Megacz [mailto:gcj@lists.megacz.com]
>> Sent: Monday, December 17, 2001 3:12 PM
>> To: java@gcc.gnu.org
>> Subject: Re: timetable change on mingw-libgcj
>>
>>
>>
>> Adam Megacz <gcj@lists.megacz.com> writes:
>>>> boehm-gc will need some porting to work with darwin's threads,
>>>> because they don't have pthread_kill implemented.
>>
>>> Ugh, that's not good. Not good....
>>
>> Actually, I was reading the boehm-gc docs, and it appears that
>> boehm-gc needs a few extensions to pthreads, which are implemented
>> differently on different platforms.
>>
>> Is there another platform that implements the same set (or a subset)
>> of pthreads extension functionality as MacOSX? That way I could simply
>> copy over that part of the configure.in switch case to get myself up
>> and running quickly.
>>
>>   - a
>>