You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Tim Ellison <t....@gmail.com> on 2006/06/20 10:39:10 UTC

Attaching threads to classlib (was: Re: [jchevm+classlibadapter] Running classlib tests)

Archie Cobbs wrote:
> Ivan Volosyuk wrote:
>> IMHO, Archie's suggestion is simplier and less intrusive, as the
>> function Thread.attachInternal() can be native function implemented in
>> classlibadapter itself.
> 
> But Graeme is correct in that there could be initialization delay.
> I.e., if we're following the normal rules of Java, all the initialization
> associated with java.lang.Object, java.lang.String, etc. will have to
> occur before the very first thread can invoke any methods in
> java.lang.Thread (even if native).
> 
> The idea is salvagable if we have a special classlib-specific launcher
> (i.e., C program using the JNI invocation interface to launch the JVM)

We do have a Harmony launcher [1] that sets up the VMI structure to pass
through to the VM and uses JNI invocation.

[1]
http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/native-src/shared/launcher/

> which did the very first thread_attach() for the main thread. Then all
> the other threads could use Thread.attachThread() or whatever without
> all the initialization delay.

We could attach the primordial thread in the launcher but of course that
would not help when the VM is embedded in some other program and doesn't
have the launcher's help.

VMs should also be aware that attaching a thread that is already
attached will set the hythread_t pointer arg to the original struct, and
increment the attachment count.

> Yet another idea (probably not feasible) would be for classlib to:
> 
> (a) check whether thread_attach() has been called yet for the current
>     thread in any native method that requires this to be so, and if not,
>     go ahead and do it itself

This is do-able too by hijacking the THREAD_SELF macro, but a bit of a
hack, and doesn't give a good story for thread death.

> (b) store its state in a ThreadLocal (so cleanup would be automatic)

Well, unless you have to do some work on the thread death, if it were
just TLS data then yes.

Regards,
Tim

> This would eliminate the requirement for the VM to be classlib-aware.
> 
> -Archie
> 
> __________________________________________________________________________
> Archie Cobbs      *        CTO, Awarix        *      http://www.awarix.com
> 
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> 
> 

-- 

Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.


---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org