[drlvm][threading] synchronizing native and java access of the thread state (Harmony-3289)

[Weldon Washburn <we...@gmail.com>]

I decided to put a response to H3289 on the dev list since it is a general
threading issue.  Please look at 3289 for background info.

In response to the question about JVMTI functions being able to grab a lock
in java.lang.Thread class, maybe a workable approach would be to replace
locking the java object with a mutex created in native code and stuffed into
a private int field of java.lang.Thread.  The Java code would use  native
method APIs to grab and release this new native mutex.   And the native code
(including JVMTI) would use the standard hymutex_lock(), hymutex_unlock().
The native code would manage the life-cycle of the private int field
containing a pointer to the native mutex.



-- 
Weldon Washburn
Intel Enterprise Solutions Software Division

Re: [drlvm][threading] synchronizing native and java access of the thread state (Harmony-3289)

[Weldon Washburn <we...@gmail.com>]

On 3/4/07, Xiao-Feng Li <xi...@gmail.com> wrote:
>
> If the thread states query and modification methods are mostly native,
> I think a native lock is more feasible. Then we don't need a special
> trick to stuff a java object with a "native" field.


hmm... my guess is that we still have the same problem which is the need to
query java  thread state from Java as well as from native code.  Note a java
app can keep a java.lang.Thread around even if the thread has exited.  And
it can query if this thread is still alive.  If the "isAlive" field is not
inside java.lang.Thread, then I guess it would have to be in struct HyThread
and somehow this struct would have to remain connected to the
java.lang.Thread as long as j.l.Thread is reachable from java code.

Btw, native methods, including JVMTI, can use native monitor APIs to
> access the Java object lock. But I would prefer native locking for
> threading operations.
>
> Thanks,
> xiaofeng
>
> On 3/5/07, Weldon Washburn <we...@gmail.com> wrote:
> > I decided to put a response to H3289 on the dev list since it is a
> general
> > threading issue.  Please look at 3289 for background info.
> >
> > In response to the question about JVMTI functions being able to grab a
> lock
> > in java.lang.Thread class, maybe a workable approach would be to replace
> > locking the java object with a mutex created in native code and stuffed
> into
> > a private int field of java.lang.Thread.  The Java code would
> use  native
> > method APIs to grab and release this new native mutex.   And the native
> code
> > (including JVMTI) would use the standard hymutex_lock(),
> hymutex_unlock().
> > The native code would manage the life-cycle of the private int field
> > containing a pointer to the native mutex.
> >
> >
> >
> > --
> > Weldon Washburn
> > Intel Enterprise Solutions Software Division
> >
>



-- 
Weldon Washburn
Intel Enterprise Solutions Software Division

Re: [drlvm][threading] synchronizing native and java access of the thread state (Harmony-3289)

[Xiao-Feng Li <xi...@gmail.com>]

If the thread states query and modification methods are mostly native,
I think a native lock is more feasible. Then we don't need a special
trick to stuff a java object with a "native" field.

Btw, native methods, including JVMTI, can use native monitor APIs to
access the Java object lock. But I would prefer native locking for
threading operations.

Thanks,
xiaofeng

On 3/5/07, Weldon Washburn <we...@gmail.com> wrote:
> I decided to put a response to H3289 on the dev list since it is a general
> threading issue.  Please look at 3289 for background info.
>
> In response to the question about JVMTI functions being able to grab a lock
> in java.lang.Thread class, maybe a workable approach would be to replace
> locking the java object with a mutex created in native code and stuffed into
> a private int field of java.lang.Thread.  The Java code would use  native
> method APIs to grab and release this new native mutex.   And the native code
> (including JVMTI) would use the standard hymutex_lock(), hymutex_unlock().
> The native code would manage the life-cycle of the private int field
> containing a pointer to the native mutex.
>
>
>
> --
> Weldon Washburn
> Intel Enterprise Solutions Software Division
>