So where are we here?
On Sep 28, 2006, at 12:41 AM, Evgueni Brevnov wrote:
On 9/28/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
On 9/26/06, Evgueni Brevnov <[EMAIL PROTECTED]> wrote:
>
> On 9/27/06, Andrey Chernyshev <[EMAIL PROTECTED]> wrote:
> > (3)
> > One more lock is added - hythread_lib_lock. How is that differ
from
> > the hythread_global_lock that we already have? Each extra lock
to the
> > system may add more possibilities for deadlocks, as well as can
> > negatively impact the scalability (unless some of the existing
locks
> > are split).
> hythread_lib_lock acquires exactly the same lock as
> hythread_global_lock. Probably I miss something but we need to be
> compatible with IBM threading library now. This library has such
> function. That's why I added it. Sounds right?
Well, this sort of, kind of sounds right but not quite. Its a
little more
subtle than being compatible with IBM threading library. The
first goal is
to identify the parts of IBM threading library that are JVM
independent. It
makes sense for DRLVM to be compatible with the independent
parts. This
should be a nobrainer.
The parts of IBM threading library that assume a specific JVM
implementation
will be a problem. We will need to find a solution that is
endorsed by all
the stakeholders (including J9 folks). The hythread_global_lock
falls into
this category. For starts, I would like to see a concise
description from
the portlib owners on what hythread_global_lock protects, which
locks have
to be held before grabbing this lock, are there any restrictions
on what
system calls can be made while holding this lock (like sleep or
wait), etc.
Weldon, I completely agree with what your are saying. It's common
problem of current hythread that should be resolved some how. I just
go inline with current implementation and added two missing functions.
Missing these can lead to the same problems as with hythread_exit
discussed in another thread "[drlvm] [launcher] Executable hangs".
To get a better idea what's in the patch.diff, I printed it out.
Its 120+
pages. Quite a big patch! Most of it looks like straight forward
JNI
interface glue. There are some tricky parts. I would like to
know the
design review process for these parts. Using grep, I found 20
locations
where ...suspend_enable... and ...suspend_disable... have been
added. And
25 locations where enable/disable have been removed. Failure in
this logic
can lead to incorrect reference pointer enumeration. These are
probably the
hardest bugs to find. Please tell us who has looked at this code
in depth.
Only me and you :-) Honetsly I think it happpens now....
Are there any known design flaws in it?
I can think of two possible problems we may want to discuss.
1) Should native threads have "daemon" status or its completely java
notion? This is TM related thing.
2) Should we attach thread to VM before attaching it to TM by calling
jthread_atatch OR jthread_attach should callback VM to attach a thread
to it? I didn't change original design of TM here ...... it implements
second choice.
I also notice APIs called tmn_suspend_enable(),
hythread_suspend_enable()
-- are these simply different names for the same binary
executible. Or
different binaries that do the same thing??
No, this is not just different names. tm_suspend_enable asserts that
thread is in disabled state before calling hythread_suspend_enable (in
debug mode only).
Thanks
Evgueni
--
> Weldon Washburn
> Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
