This is the mail archive of the java-patches@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: preliminary invocation patch


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]