Re: portable-native-sync-5.patch

[Steven Augart]

Mark,

Thank you for the careful review.  Your points are good, and I have 
already incorporated some of your comments into my working sources.

I do have an answer to one of your questions, though:

Mark Wielaard wrote:
> Can't we assume that jobject and gpointer are both (void *) so we don't
> need the int <-> Thread (global jobject ref) mapping?
> Maybe there are platforms where jobject and gpointer aren't the same,
> but I guess that is pretty unlikely.

I agree with you on the pointer size issues.  A gpointer is a void *, 
so it's certainly guaranteed to be at least as large as any other 
pointer. And a jobject is implicitly an opaque pointer (in Jikes RVM, 
we use small integers, but we coerce them into the representation of a 
pointer).

The int <==> Thread mapping addresses a different issue.  I realize 
that I did not document this properly (two and a half lines in 
thread_create), and the point is subtle (at least to me; took me a 
while to figure out).

The int => Thread mapping always returns jobjects that are local 
references, not global ones.  This is because Thread objects need to 
be able to go away and be garbage collected after the thread they 
refer to has died.

If we keep a global object reference to a thread, then when do we 
delete that global object reference?  We have an answer in the case of 
GThread objects that were explicitly created with the joinable 
attribute.  It is safe for us to maintain a global reference to any 
joinable thread, since the joinable thread must sticks around (even if 
only in a zombie state) until it's explicitly joined via a 
g_thread_join() call.  The global ref could be cleaned up at that 
point too.

However, in the case of GThreads that were created non-joinable by 
g_thread_create(), and in the case of Java threads that were created 
within pure Java code (not via g_thread_create()), we don't want them 
to linger around forever, and there is no way to tell when the last 
reference to such threads needs to expire.  In the case of this 
application -- AWT with GTK peers -- it would probably be safe anyway, 
since there are not very many threads we create, but I was going for 
correctness even in the case of long-running programs that might set 
up and tear down AWT interfaces many times.

So, I duplicated the POSIX thread-ID semantics.  The thread ID of a 
non-joinable thread remains valid as long as that thread is still 
alive.  Once that thread dies, the old thread ID may be reused at any 
moment.  And that's why the array indexed by thread ID numbers is an 
array of weak references.

That's also why the int => Thread jobject mapping function always 
returns local references, since global references would lock the 
Thread in memory forever.

I would dearly love there to be a cleaner solution.  I dislike the 
repeated dips from C code into Java that are necessary to look up 
thread ID numbers.  If anyone can think of one, I'm all ears.

--
Steven Augart

Jikes RVM, a free, open source, Virtual Machine:
http://oss.software.ibm.com/jikesrvm