harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Evgueni Brevnov" <evgueni.brev...@gmail.com>
Subject Re: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
Date Thu, 28 Sep 2006 13:19:29 GMT
I suppose two days silence means that there is no objects (maybe
interest) against proposed patch. I would suggest to commit it ASAP.
It really works! There are some cases when current VM crashes but the
patch fixes it. I can work on bringing cunit tests to live as soon as
the patch is committed.... This is just my understanding.

Thanks
Evgueni

On 9/28/06, Geir Magnusson Jr. <geir@pobox.com> wrote:
> So where are we here?
>
> On Sep 28, 2006, at 12:41 AM, Evgueni Brevnov 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....
> >
> >> 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
> >
>
>
> ---------------------------------------------------------------------
> 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
>
>

---------------------------------------------------------------------
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


Mime
View raw message