This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: preliminary invocation patch
Jeff Sturm <jsturm@one-point.com> writes:
> This is cool. Have you seen any of the draft suggestions for an
> invocation API, and did they influence your patch?
Oops. I'd forgotten about them. Do you have a pointer?
> I'm wondering if this shouldn't register the thread with GC as well.
> Currently boehm-gc autoregisters all threads on GNU/Linux by wrapping
> pthread_create(). But other ports may not. Also, the wrapping
> technique may lose on JNI.
>
> So I'd argue for a corresponding _Jv_GCThreadRegister API call, even if
> boehm-gc ignores it right now.
At some point it might be nice to make some other fixes of the API.
For example, have _Jv_ThreadRegister that a Thread, rather than a
_Jv_Thread_t. And make the thread field of natThread be a (_Jv_Thread_t)
rather than a (_Jv_Thread_t*). And perhaps make JNIEnv be a synonym
for natThread. I think this would simplify things: make them more
efficient and simplier to understand. Then you would not need a
separate _Jv_GCThreadRegister. But such changes require changing the
include files around, and I don't think we want to do that right now.
> By removing _Jv_ThreadWait you change the behavior of JvRunMain. It
> shouldn't exit until all non-daemon threads have terminated.
Ah yes, I had forgotten about that.
I'll add the _Jv_ThreadWait back.
> This comment suggests finish_ releases any remaining monitors. Does it
> really? That doesn't seem easy to do without somehow unwinding the
> stack.
I don't know. The code is loosely based on the JNI version. I suspect
think will work in most cases, but will probably not be correct in
some cases.
--
--Per Bothner
per@bothner.com http://www.bothner.com/per/