harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gregory Shimansky (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HARMONY-3647) [drlvm][thread] Issues with native threads creation and termination
Date Wed, 18 Apr 2007 15:21:16 GMT

    [ https://issues.apache.org/jira/browse/HARMONY-3647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489786

Gregory Shimansky commented on HARMONY-3647:

Yes, in the constructor of j.l.Thread for a native thread (the one which uses 6 arguments)
context class loader is set only for the main thread to be system class loader. According
to the JNI spec, and native thread attached to the VM http://java.sun.com/j2se/1.5.0/docs/guide/jni/spec/invocation.html#attach_current_thread
has bootstrap class loader. So it could be that the test is just designed that it doesn't
handle such situations correctly. I've seen the fix in HARMONY-3671 and I am not sure whether
to consider it as a workaround...

> [drlvm][thread] Issues with native threads creation and termination
> -------------------------------------------------------------------
>                 Key: HARMONY-3647
>                 URL: https://issues.apache.org/jira/browse/HARMONY-3647
>             Project: Harmony
>          Issue Type: Bug
>          Components: DRLVM
>         Environment: Win/Linux
>            Reporter: Li-Gang Wang
> While I tested the native finref (finalizer & ref enqueue) thread implementation,
I met two issues about native thread creation and termination. I have only temporary workarounds
for them currently. The basic issue is how to create/terminate a native thread that has associated
java.lang.Thread object.
> 1.        On Win & Linux, jvmti.test failed occasionally
> CAUSE: We couldn't attach finref threads as Java threads atomically with the according
interface, attach_current_thread(). The attaching action may contend some lock with the main
thread. When we ran jvmti.test, if the main thread held the lock firstly, finref threads had
to run Thread class's constructor before they were associated to a Java thread structure.
This would incur failure.
> The related issue is on Jira is https://issues.apache.org/jira/browse/HARMONY-3578.
> In this patch I make the main thread wait until all finref threads finish their attaching
> 2.    On Win, gc.FinAlloc test hung after it printed "PASSED" once per tens of times.
> CAUSE: In vm_destroy(), finref threads are signaled to terminate and then the main thread
terminates itself. But the termination of native threads is not atomic, so sometimes finref
threads were not terminated properly and held a shared lock after termination. In this situation
when the main thread was calling Thread.detach() method to detach itself, it could not hold
the lock and was blocked.
> The related issue is on Jira is https://issues.apache.org/jira/browse/HARMONY-3588.
> In this patch, when VM signals finref threads to terminate, it will wait until the termination
action finishes.
> With the exploration, I suspect that current design in DRLVM might require this kind
of native thread (that has associated j.l.thread object) to be treated as real Java thread,
and created in Java code. That is, it doesn't allow the VM to simply create a native thread
to be associated with a j.l.thread object. We need this kind of thread because we need them
to run Java methods (the finalizers). I guess  this should be a bug in current design, since
the main thread must be created from native thread but able to run main() method of the entry

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message