harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject Re: [drlvm] HARMONY-1582 - invocation API for DRLVM
Date Thu, 28 Sep 2006 16:31:14 GMT
On 9/27/06, Evgueni Brevnov <evgueni.brevnov@gmail.com> wrote:
>
> On 9/28/06, Weldon Washburn <weldonwjw@gmail.com> wrote:
> > On 9/26/06, Evgueni Brevnov <evgueni.brevnov@gmail.com> wrote:
> > >
> > > On 9/27/06, Andrey Chernyshev <a.y.chernyshev@gmail.com> 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....



You and Andrey Chernyshev and me need to review enable/disable very closely
very soon.  bugs in this area can lead to all sorts of hard to diagnose
instability.

> 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: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>


-- 
Weldon Washburn
Intel Middleware Products Division

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message