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 Mon, 02 Oct 2006 14:25:39 GMT
I've updated https://issues.apache.org/jira/browse/HARMONY-1582.
It fixes several places according to discussions on the list. Namely

1) move "daemon" attribute from native to java layer.
2) return jthread_create signature back
3) remove hythread_create_ex
4) fix unexpected bug in encoder
5) split patches for vm and build modules.


On 10/2/06, Evgueni Brevnov <evgueni.brevnov@gmail.com> wrote:
> On 9/30/06, Weldon Washburn <weldonwjw@gmail.com> wrote:
> > Evgueni,
> >
> > +1   provided "build, build test" run on Windows, Redhat and Unbuntu.
> >
> > I looked carefully at all the enable/disable sites. AFAICT, they look
> > perfect.  You did a good job!
>
> Thank you!
>
> >
> > Please correct me if I am wrong, the enable/disable sites are in "JNI"
> > methods where you need to step outside of JNI environment to actually touch
> > a slot holding a reference ptr.  In which case, you need to disable, access
> > the slot, then re-enable suspension.
>
> Correct.
>
> >
> > I agree that supporting multiple JVMs in one addr space is a non-goal for
> > drlvm at this time.  But at the same time it make sense to be as compatible
> > as possible with portlib.  Portlib is really setup to expect multiple JVM in
> > one addr space environment.  The bottom line is we should put in whatever
> > hooks portlib but only run drlvm in "one vm per addr space" mode.
>
> Sounds reasonable for me.
>
> Evgueni
> >
> >
> > On 9/29/06, Evgueni Brevnov <evgueni.brevnov@gmail.com> wrote:
> > >
> > > Weldon that's cool if you review the patch. Regarding enable/disable
> > > switching. I agree here such bugs are quite hard to fix. Actually I
> > > think it is a good indicator that you found 25 (don't remember
> > > exactly) enable/disable switching. It was really suspicious if you
> > > hadn't find any disabled region :-)
> > >
> > > I will update the patch as with respect to your recommendations very
> > > soon....
> > >
> > > Evgueni
> > >
> > > On 9/29/06, Tim Ellison <t.p.ellison@gmail.com> wrote:
> > > > IMHO Weldon is making a perfectly reasonable request.  If he is willing
> > > > to look through the patch in detail then waiting a day or two on
> > > > progressing other items is well worth it.
> > > >
> > > > Just my 2c.
> > > >
> > > > Tim
> > > >
> > > > Weldon Washburn wrote:
> > > > > 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
> > > > >>
> > > > >>
> > > > >
> > > > >
> > > >
> > > > --
> > > >
> > > > Tim Ellison (t.p.ellison@gmail.com)
> > > > IBM Java technology centre, UK.
> > > >
> > > > ---------------------------------------------------------------------
> > > > 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
> >
> >
>

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