[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: portable-native-sync-5.patch
From: |
Steven Augart |
Subject: |
Re: portable-native-sync-5.patch |
Date: |
Mon, 24 May 2004 12:24:05 -0400 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040421 |
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