This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: preliminary invocation patch
- To: Per Bothner <per at bothner dot com>
- Subject: Re: preliminary invocation patch
- From: Jeff Sturm <jsturm at one-point dot com>
- Date: Tue, 15 May 2001 22:13:16 +0100
- CC: java-patches at gcc dot gnu dot org
- References: <m2g0e61hkv.fsf@kelso.bothner.com>
Per Bothner wrote:
> Below is a preliminary patch (relative to the libjava directory of the
> gcc3.0 branch) that adds support for a CNI invocation interface and
> the JNI invocation interface. It no longer uses NativeThread or
> FirstThread - the first thread is now the C++ "main" thread.
This is cool. Have you seen any of the draft suggestions for an
invocation API, and did they influence your patch?
> I would especially appreciate testing on Windows.
The Windows build is currently broken. I expect that'll be fixed on the
trunk sometime soon. Meanwhile if anybody has a hacked libgcj using
win32-threads.cc they may be able to give this a try.
> +void
> +_Jv_ThreadRegister (_Jv_Thread_t *data)
> +{
> +
> + pthread_setspecific (_Jv_ThreadKey, data->thread_obj);
> + pthread_setspecific (_Jv_ThreadDataKey, data);
> +
> + // glibc 2.1.3 doesn't set the value of `thread' until after start_routine
> + // is called. Since it may need to be accessed from the new thread, work
> + // around the potential race here by explicitly setting it again.
> + data->thread = pthread_self ();
> +}
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.
Ditto for _Jv_ThreadUnRegister.
> @@ -846,11 +882,9 @@ JvRunMain (jclass klass, int argc, const
> _Jv_ThisExecutable (argv[0]);
> #endif
>
> + main_thread = _Jv_AttachCurrentThread (JvNewStringLatin1 ("main"), NULL);
> arg_vec = JvConvertArgv (argc - 1, argv + 1);
> - main_thread = new gnu::gcj::runtime::FirstThread (klass, arg_vec);
> -
> - main_thread->start();
> - _Jv_ThreadWait ();
By removing _Jv_ThreadWait you change the behavior of JvRunMain. It
shouldn't exit until all non-daemon threads have terminated.
> +jint
> +_Jv_DetachCurrentThread (void)
> +{
> + java::lang::Thread *t = _Jv_ThreadCurrent ();
> + if (t == NULL)
> + return -1;
> +
> + _Jv_ThreadUnRegister ();
> + // Release the monitors.
> + t->finish_ ();
This comment suggests finish_ releases any remaining monitors. Does it
really? That doesn't seem easy to do without somehow unwinding the
stack.
Jeff