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 CHECKPOINT
Date Fri, 29 Sep 2006 04:41:50 GMT
On 9/28/06, Evgueni Brevnov <evgueni.brevnov@gmail.com> wrote:
>
> 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.


Sorry for not being clear.  I had asked in another thread for a readable
diff.  As I said before, hacking around with gc enable/disable without
careful review is a great way to introduce all sorts of hard to
diagnose intermittant threading/gc bugs.  The existing "build test" does not
even come close to stressing threading/gc.  Its hard to say if this patch
really works at this point.

I request a decent diff and 24 hours for Andrey Cherneyshev and me to
review.  I think the following will work:

 "svn diff  --diff-cmd diff.exe  -x  -w  -x  -B"


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


-- 
Weldon Washburn
Intel Middleware Products Division

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