You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Evgueni Brevnov <ev...@gmail.com> on 2006/09/28 15:19:29 UTC
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
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. <ge...@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 <we...@gmail.com> wrote:
> >> On 9/26/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> >> >
> >> > On 9/27/06, Andrey Chernyshev <a....@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
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
Posted by Evgueni Brevnov <ev...@gmail.com>.
On 10/3/06, Artem Aliev <ar...@gmail.com> wrote:
> Evgueni,
Artem,
>
> 1) Which of the patches is a final?
invocation_api.4.patch is final..... so far :-)
>
> 2) It looks like you do not find a way to remove hythread_library_t
> from parameters
> and JavaVM from thread manager code. Well, leave it as is, I will try
> to fix this later.
No problems, I agree to review it later....
>
> 2)
> Is the following global variable is necessary?
> > extern hythread_library_t TM_LIBRARY;
Unfortunately, yes. I believe we need to get rid of that for
multi-VM.... but it seems to be another story...
Thanks a lot
Evgueni
>
> Thanks
> Artem
>
> ---------------------------------------------------------------------
> 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
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
Posted by Artem Aliev <ar...@gmail.com>.
Evgueni,
1) Which of the patches is a final?
2) It looks like you do not find a way to remove hythread_library_t
from parameters
and JavaVM from thread manager code. Well, leave it as is, I will try
to fix this later.
2)
Is the following global variable is necessary?
> extern hythread_library_t TM_LIBRARY;
Thanks
Artem
---------------------------------------------------------------------
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
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
Posted by Evgueni Brevnov <ev...@gmail.com>.
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 <ev...@gmail.com> wrote:
> On 9/30/06, Weldon Washburn <we...@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 <ev...@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....@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 <ev...@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. <ge...@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 <we...@gmail.com> wrote:
> > > > >> > >> On 9/26/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> > > > >> > >> >
> > > > >> > >> > On 9/27/06, Andrey Chernyshev <a....@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
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
Posted by Evgueni Brevnov <ev...@gmail.com>.
On 9/30/06, Weldon Washburn <we...@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 <ev...@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....@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 <ev...@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. <ge...@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 <we...@gmail.com> wrote:
> > > >> > >> On 9/26/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> > > >> > >> >
> > > >> > >> > On 9/27/06, Andrey Chernyshev <a....@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
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
Posted by Weldon Washburn <we...@gmail.com>.
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!
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.
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.
On 9/29/06, Evgueni Brevnov <ev...@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....@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 <ev...@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. <ge...@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 <we...@gmail.com> wrote:
> > >> > >> On 9/26/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> > >> > >> >
> > >> > >> > On 9/27/06, Andrey Chernyshev <a....@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
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
Posted by Evgueni Brevnov <ev...@gmail.com>.
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....@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 <ev...@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. <ge...@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 <we...@gmail.com> wrote:
> >> > >> On 9/26/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> >> > >> >
> >> > >> > On 9/27/06, Andrey Chernyshev <a....@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
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
Posted by Tim Ellison <t....@gmail.com>.
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 <ev...@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. <ge...@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 <we...@gmail.com> wrote:
>> > >> On 9/26/06, Evgueni Brevnov <ev...@gmail.com> wrote:
>> > >> >
>> > >> > On 9/27/06, Andrey Chernyshev <a....@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
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
Posted by Weldon Washburn <we...@gmail.com>.
On 9/28/06, Evgueni Brevnov <ev...@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. <ge...@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 <we...@gmail.com> wrote:
> > >> On 9/26/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> > >> >
> > >> > On 9/27/06, Andrey Chernyshev <a....@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
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
Posted by Evgueni Brevnov <ev...@gmail.com>.
yes I see them too. I see them even w/o my patch :-( sure, it need to
be fixed...
On 10/9/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> btw, why are there so many warnings? I'm not comfortable with having
> to suppress them - I'd rather fix them...
>
> On Oct 9, 2006, at 9:49 AM, Geir Magnusson Jr. wrote:
>
> > sure - I'll redo the whole thing from clean...
> >
> >
> > On Oct 9, 2006, at 9:45 AM, Evgueni Brevnov wrote:
> >
> >> BTW, could you verify the right patch for tests was used? It
> >> should be
> >> tests.final.2.patch...... Sorry for the mess with patches....
> >>
> >> Evgueni
> >>
> >> On 10/9/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> >>> I put debug printing into test_ti_instrum.c and attached it to JIRA.
> >>> Could you run it on your machine and send me console output.
> >>>
> >>> Evgueni
> >>>
> >>> On 10/9/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> >>> > I keep getting a failure when running the tests -
> >>> >
> >>> > test_jthread_get_all-threads failling the assertion at
> >>> > test_ti_instrum.c:80
> >>> >
> >>> > geir
> >>> >
> >>> > On Oct 8, 2006, at 7:19 AM, Evgueni Brevnov wrote:
> >>> >
> >>> > > While running cunit on Linux it turned out one test case
> >>> fails some
> >>> > > time. The fix is in tests.final.2.patch.
> >>> > >
> >>> > > So the last versions to be committed:
> >>> > > invocation_api.final.patch
> >>> > > build.final.2.patch
> >>> > > tests.final.2.patch
> >>> > >
> >>> > > Evgueni
> >>> > >
> >>> > >
> >>> > > On 10/8/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> >>> > >> I mahaged to resolve the problem on Linux.... will update
> >>> > >> build.final.patch with build.final.2.patch in a while
> >>> > >>
> >>> > >> On 10/8/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> >>> > >> > Hi,
> >>> > >> >
> >>> > >> > Oh! Ooh! I did that..... I passed cunit, somke, kernel
> >>> tests on
> >>> > >> > Windows and smoke, kernel tests on Linux. Unfortunately I
> >>> failed to
> >>> > >> > link cunit tests on Linux so far. So I disabled cunit on
> >>> Linux
> >>> > >> until
> >>> > >> > the problem is solved. I believe it is acceptable as short
> >>> term
> >>> > >> > solution. I found several problems in cunit tests. I will
> >>> come
> >>> > >> up with
> >>> > >> > my findings later (not today).
> >>> > >> >
> >>> > >> > Use latest patches from HARMONY-1582. They are marked as
> >>> final.
> >>> > >> There
> >>> > >> > are three patches. One for build module, one for cunit
> >>> tests and
> >>> > >> one
> >>> > >> > for VM itself.
> >>> > >> >
> >>> > >> > Thanks
> >>> > >> > Evgueni
> >>> > >> >
> >>> > >> >
> >>> > >> > On 10/6/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> >>> > >> > > Nooooooo! LOL
> >>> > >> > >
> >>> > >> > > I'm here waiting - This will unblock a whole bunch of
> >>> things :)
> >>> > >> > >
> >>> > >> > > Thanks for the effort
> >>> > >> > >
> >>> > >> > > Evgueni Brevnov wrote:
> >>> > >> > > > Geir,
> >>> > >> > > >
> >>> > >> > > > That's terrible. We have power outage....servers are
> >>> down. I
> >>> > >> can't
> >>> > >> > > > send the patches now.... will do it tomorrow
> >>> > >> > > >
> >>> > >> > > > Evgueni
> >>> > >> > > > On 10/5/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> >>> > >> > > >> woo hoo! here we go...
> >>> > >> > > >>
> >>> > >> > > >>
> >>> > >> > > >> Andrey Chernyshev wrote:
> >>> > >> > > >> > Hi Evgueni,
> >>> > >> > > >> >
> >>> > >> > > >> > On 10/4/06, Evgueni Brevnov
> >>> <ev...@gmail.com>
> >>> > >> wrote:
> >>> > >> > > >> >> Hi All,
> >>> > >> > > >> >>
> >>> > >> > > >> >> I have attached updated patch to the JIRA. It should
> >>> > >> resolve remain
> >>> > >> > > >> >> concerns. Andrey, could you give a green light now?
> >>> > >> > > >> >
> >>> > >> > > >> > Thanks for updating the patch! I agree it it can be
> >>> > >> committed, at
> >>> > >> > > >> > least signatures look good. 5 revisions seem like more
> >>> > >> than enough :).
> >>> > >> > > >> > Anyways, I think the remaining issues can be resolved
> >>> > >> with additional
> >>> > >> > > >> > patches. Thanks again for the good work and your
> >>> patience.
> >>> > >> > > >> >
> >>> > >> > > >> > Thanks,
> >>> > >> > > >> > Andrey.
> >>> > >> > > >> >
> >>> > >> > > >> >>
> >>> > >> > > >> >> Thanks
> >>> > >> > > >> >> Evgueni
> >>> > >> > > >> >>
> >>> > >> > > >> >> On 10/4/06, Evgueni Brevnov
> >>> <ev...@gmail.com>
> >>> > >> wrote:
> >>> > >> > > >> >> > Andrey,
> >>> > >> > > >> >> >
> >>> > >> > > >> >> > I see your points. I think both approaches have
> >>> > >> advantages and
> >>> > >> > > >> >> > disadvantages. I think it is quite hard to say
> >>> which
> >>> > >> approach is
> >>> > >> > > >> >> > better until we play with one VM only. I still feel
> >>> > >> like introducing
> >>> > >> > > >> >> > one more dependence is better than spreading code
> >>> > >> which deals with
> >>> > >> > > >> >> > attachment among VM and TM. We really get stuck.
> >>> OK,
> >>> > >> just because I
> >>> > >> > > >> >> > want to move forward I will do required changes
> >>> to remove
> >>> > >> > > >> >> > vm_create_jthread from TM. I believe that will
> >>> resolve
> >>> > >> all our
> >>> > >> > > >> >> > disagreements and the patch will be applied soon.
> >>> > >> > > >> >> >
> >>> > >> > > >> >> >
> >>> > >> > > >> >> > Thanks
> >>> > >> > > >> >> > Evgueni.
> >>> > >> > > >> >> >
> >>> > >> > > >> >> > On 10/4/06, Andrey Chernyshev
> >>> > >> <a....@gmail.com> wrote:
> >>> > >> > > >> >> > > On 10/3/06, Evgueni Brevnov
> >>> > >> <ev...@gmail.com> wrote:
> >>> > >> > > >> >> > > > On 10/3/06, Andrey Chernyshev
> >>> > >> <a....@gmail.com> wrote:
> >>> > >> > > >> >> > > > > On 10/2/06, Evgueni Brevnov
> >>> > >> <ev...@gmail.com> wrote:
> >>> > >> > > >> >> > > > > > Andrey,
> >>> > >> > > >> >> > > > > >
> >>> > >> > > >> >> > > > > > Just to be clear.... I agree with you it
> >>> is more
> >>> > >> > > >> convenient if
> >>> > >> > > >> >> > > > > > jthread_create takes JNIEnv instead of
> >>> JavaVM. It
> >>> > >> > > >> reflects that
> >>> > >> > > >> >> > > > > > current thread has been attached
> >>> already. Do
> >>> > >> you think it
> >>> > >> > > >> >> makes sense
> >>> > >> > > >> >> > > > > > to get rid of JNIEnv and use
> >>> > >> jthread_get_JNI_env in that
> >>> > >> > > >> case?
> >>> > >> > > >> >> > > > >
> >>> > >> > > >> >> > > > > The jthread_* layer is designed like if it
> >>> were
> >>> > >> a regular JNI
> >>> > >> > > >> >> > > > > application which is meant to be called
> >>> from the
> >>> > >> Java code,
> >>> > >> > > >> hence
> >>> > >> > > >> >> > > > > every function on that layer receives
> >>> JNIenv. We
> >>> > >> can probably
> >>> > >> > > >> >> get rid
> >>> > >> > > >> >> > > > > of the JNEnv parameter for jthread_*
> >>> functions,
> >>> > >> assuming that
> >>> > >> > > >> >> TM can
> >>> > >> > > >> >> > > > > always extract JNIenv for the current
> >>> thread with
> >>> > >> > > >> >> > > > > jthread_get_JNI_env().
> >>> > >> > > >> >> > > > > My only concern would be the performance
> >>> - once
> >>> > >> the JNIenv is
> >>> > >> > > >> >> already
> >>> > >> > > >> >> > > > > known for the native part of the kernel
> >>> classes
> >>> > >> impl, it
> >>> > >> > > >> must be
> >>> > >> > > >> >> > > > > cheaper to pass JNIEnv to TM as an extra
> >>> > >> parameter rather than
> >>> > >> > > >> >> extract
> >>> > >> > > >> >> > > > > it from the TLS again.
> >>> > >> > > >> >> > > > > Other than that, I see no strong
> >>> advantages in
> >>> > >> keeping JNIEnv
> >>> > >> > > >> >> parameter.
> >>> > >> > > >> >> > > > >
> >>> > >> > > >> >> > > > >
> >>> > >> > > >> >> > > > > > Regarding jthread_attach. I still didn't
> >>> get
> >>> > >> your point....
> >>> > >> > > >> >> Clarify it
> >>> > >> > > >> >> > > > > > please if you think jhread_attach should be
> >>> > >> modified.
> >>> > >> > > >> >> > > > >
> >>> > >> > > >> >> > > > > Sorry for being not clear: I think for
> >>> > >> jthread_attach, we have
> >>> > >> > > >> >> two options:
> >>> > >> > > >> >> > > > > 1) Make JNIEnv input parameter - it must
> >>> be new
> >>> > >> JNIEnv that VM
> >>> > >> > > >> >> > > > > pre-allocates for the new Java thread.
> >>> > >> jthread_attach
> >>> > >> > > >> would just
> >>> > >> > > >> >> > > > > associate it with the current thread.
> >>> > >> > > >> >> > > > >
> >>> > >> > > >> >> > > > > 2) Obtain JNIEnv via vm_attach() callback. In
> >>> > >> this case, if
> >>> > >> > > >> >> > > > > vm_attach() callback implementation needs to
> >>> > >> know for which
> >>> > >> > > >> >> JavaVM new
> >>> > >> > > >> >> > > > > JNIenv has to be allocated, then we'll
> >>> need to
> >>> > >> add JavaVM as
> >>> > >> > > >> >> input
> >>> > >> > > >> >> > > > > parameter for jthread_attach().
> >>> > >> > > >> >> > > > > I think both options should be fine, (1)
> >>> would
> >>> > >> probably
> >>> > >> > > >> keep TM
> >>> > >> > > >> >> > > > > interface a bit lighter, though (2) may look
> >>> > >> more closer to
> >>> > >> > > >> >> the JNI
> >>> > >> > > >> >> > > > > invocation API idea.
> >>> > >> > > >> >> > > > > So I think adding JavaVM specifically for
> >>> > >> jthread_attach
> >>> > >> > > >> may make
> >>> > >> > > >> >> > > > > sense given the explanation you provided
> >>> earlier.
> >>> > >> > > >> >> > > > >
> >>> > >> > > >> >> > > > > The concern I would have regarding the
> >>> proposed
> >>> > >> jthread_attach
> >>> > >> > > >> >> > > > > implementation is a call to
> >>> vm_create_jthread()
> >>> > >> - this call
> >>> > >> > > >> >> introduces
> >>> > >> > > >> >> > > > > an extra dependency of TM on vmcore that I'd
> >>> > >> prefer to be
> >>> > >> > > >> >> avoided. In
> >>> > >> > > >> >> > > > > the original version, jthread_attach() was
> >>> > >> taking jthread
> >>> > >> > > >> >> argument of
> >>> > >> > > >> >> > > > > the already prepared j.l.Thread.
> >>> > >> > > >> >> > > >
> >>> > >> > > >> >> > > > I understand your concern. Unfortunately I
> >>> don't
> >>> > >> see what we
> >>> > >> > > >> can do
> >>> > >> > > >> >> > > > here. Let me explain. In the beginning you
> >>> have an
> >>> > >> unattached
> >>> > >> > > >> >> native
> >>> > >> > > >> >> > > > thread. To be able to call java code (which is
> >>> > >> required for
> >>> > >> > > >> >> > > > constructing j.l.Thread instance) the thread
> >>> > >> should be attached
> >>> > >> > > >> >> first.
> >>> > >> > > >> >> > > > To be specific it should be attached to VM by
> >>> > >> calling vm_attach
> >>> > >> > > >> >> which
> >>> > >> > > >> >> > > > will return a valid JNIEnv It is valid to
> >>> use JNI
> >>> > >> from that
> >>> > >> > > >> moment.
> >>> > >> > > >> >> > > > Obtained JNIEnv can be used to execute java
> >>> code
> >>> > >> and create
> >>> > >> > > >> >> j.l.Thread
> >>> > >> > > >> >> > > > instance. Since we do vm_attach in
> >>> jthread_attach
> >>> > >> we need to do
> >>> > >> > > >> >> > > > vm_create_jthread inside jthread_atach as well.
> >>> > >> > > >> >> > > > Of course it can be an alternative to do
> >>> vm_attach
> >>> > >> and
> >>> > >> > > >> >> > > > vm_create_jthread outside of TM right before
> >>> > >> jthread_attach.
> >>> > >> > > >> >> Sure it
> >>> > >> > > >> >> > > > will reduce one dependence between VM and
> >>> TM. But
> >>> > >> it seems like
> >>> > >> > > >> >> > > > artificial action for me just because of
> >>> > >> dependency....
> >>> > >> > > >> >> > >
> >>> > >> > > >> >> > > Why do you think it is artificial? I would rather
> >>> > >> prefer not to
> >>> > >> > > >> throw
> >>> > >> > > >> >> > > vm_attach event from the jthread_attach() call at
> >>> > >> all than to add
> >>> > >> > > >> >> > > extra dependency. The idea of jthread layer is a
> >>> > >> Java face to
> >>> > >> > > >> >> > > hythread, it is meant to know either a little or
> >>> > >> nothing about the
> >>> > >> > > >> >> > > rest of VM. It may be logical to throw vm_attach
> >>> > >> call from the
> >>> > >> > > >> newly
> >>> > >> > > >> >> > > created thread, because there is no other way
> >>> to let
> >>> > >> know VM
> >>> > >> > > >> the new
> >>> > >> > > >> >> > > thread is created. VM attach is a different
> >>> case -
> >>> > >> VM already
> >>> > >> > > >> knows
> >>> > >> > > >> >> > > about new Java thread at the time of the
> >>> > >> AttachCurrentThread call.
> >>> > >> > > >> >> > >
> >>> > >> > > >> >> > > >
> >>> > >> > > >> >> > > > > Do you think it makes sense to replace a
> >>> single
> >>> > >> jthread
> >>> > >> > > >> >> parameter with
> >>> > >> > > >> >> > > > > a variety of stuff (like thread group,
> >>> name)? It
> >>> > >> seems the
> >>> > >> > > >> only
> >>> > >> > > >> >> > > > > purpose of at these args is to be passed
> >>> back to
> >>> > >> VM for
> >>> > >> > > >> >> > > > > vm_jthread_create(). I would suggest to
> >>> change
> >>> > >> this and try
> >>> > >> > > >> doing
> >>> > >> > > >> >> > > > > either of:
> >>> > >> > > >> >> > > > > 1) Make signature of jthread_attach with 3
> >>> args,
> >>> > >> JavaVM,
> >>> > >> > > >> >> jthread and the daemon.
> >>> > >> > > >> >> > > > Why do you want to pass daemon to TM but
> >>> thread's
> >>> > >> name and
> >>> > >> > > >> >> group. Just
> >>> > >> > > >> >> > > > because current TM doesn't need such
> >>> information?
> >>> > >> What if it is
> >>> > >> > > >> >> > > > required to get thread name later? Say by
> >>> introducing
> >>> > >> > > >> >> > >
> >>> > >> > > >> >> > > I imagine you need a daemon attribute since
> >>> the TM
> >>> > >> is still
> >>> > >> > > >> managing
> >>> > >> > > >> >> > > the thread daemonality. TM is not managing thread
> >>> > >> name and group -
> >>> > >> > > >> >> > > they are all kept on the Java level, hence
> >>> passing
> >>> > >> them may be
> >>> > >> > > >> >> > > excessive.
> >>> > >> > > >> >> > >
> >>> > >> > > >> >> > > > jthread_get_name... What will you do in that
> >>> case?
> >>> > >> Let me
> >>> > >> > > >> guess you
> >>> > >> > > >> >> > > > will call j.l.Thread.getName. Right. Ok! In
> >>> that
> >>> > >> case I see no
> >>> > >> > > >> >> > > > problems to call j.l.Thread.isDaemon. Do you
> >>> > >> agree? So it
> >>> > >> > > >> doesn't
> >>> > >> > > >> >> > >
> >>> > >> > > >> >> > > As I suggested earlier, the best way to handle
> >>> > >> daemonality would
> >>> > >> > > >> >> > > probably be in pure Java - in j.l.Thread (or
> >>> > >> > > >> j.l.VMThreadManager) or
> >>> > >> > > >> >> > > whatever. You already lifted it up to the jthread
> >>> > >> level, but
> >>> > >> > > >> what if
> >>> > >> > > >> >> > > we can go a little bit higher...
> >>> > >> > > >> >> > >
> >>> > >> > > >> >> > > > seems to be a good design to pass only part
> >>> of the
> >>> > >> > > >> information to
> >>> > >> > > >> >> > > > jthread_atach. Lets look at the signature of
> >>> > >> > > >> >> AttachCurrentThread. It
> >>> > >> > > >> >> > > > takes exactly these three parameters (daemon,
> >>> > >> name, group)
> >>> > >> > > >> >> passed as a
> >>> > >> > > >> >> > > > structure. I was thinking about having
> >>> exactly the
> >>> > >> same
> >>> > >> > > >> >> structure as
> >>> > >> > > >> >> > > > third parameter of jthread_attach but it
> >>> occured
> >>> > >> to be more
> >>> > >> > > >> >> convinient
> >>> > >> > > >> >> > > > to pass them seperatly. Although I don't see
> >>> > >> strong reasons
> >>> > >> > > >> against
> >>> > >> > > >> >> > > > having a structure a third parameter.
> >>> > >> > > >> >> > >
> >>> > >> > > >> >> > > I see. Acually, I would love to keep the
> >>> > >> jthread_attach func-ty at
> >>> > >> > > >> >> the
> >>> > >> > > >> >> > > minimum level which will be needed to handle the
> >>> > >> only data that TM
> >>> > >> > > >> >> > > should be aware of. We need a formal boundary
> >>> > >> between jthread
> >>> > >> > > >> layer
> >>> > >> > > >> >> > > and vmcore (otherwise jthread won't have a
> >>> much of
> >>> > >> sense, one may
> >>> > >> > > >> >> > > consider it just as a convenience set of
> >>> functions
> >>> > >> in vmcore which
> >>> > >> > > >> >> are
> >>> > >> > > >> >> > > doing something with threading).
> >>> > >> > > >> >> > >
> >>> > >> > > >> >> > > >
> >>> > >> > > >> >> > > > > 2) Move the implementation of
> >>> vm_create_jtrhead
> >>> > >> () to
> >>> > >> > > >> >> > > > > thread_java_basic.c - could it be written in
> >>> > >> pure JNI without
> >>> > >> > > >> >> using
> >>> > >> > > >> >> > > > > internal VM API like class_alloc_new_object
> >>> ()?
> >>> > >> > > >> >> > > >
> >>> > >> > > >> >> > > > Yes, this can be done but it doesn't fix the
> >>> > >> problem. You still
> >>> > >> > > >> >> need
> >>> > >> > > >> >> > > > to know about internal constructor of
> >>> j.l.Thread
> >>> > >> > > >> >> > >
> >>> > >> > > >> >> > > That's bad. Given what you said, now it seems
> >>> that
> >>> > >> the most
> >>> > >> > > >> >> preferable
> >>> > >> > > >> >> > > sequence for AttachCurrentThread impl still
> >>> would be
> >>> > >> like:
> >>> > >> > > >> >> > > JNIEnv = vm_attach();
> >>> > >> > > >> >> > > jthread = create_jthread(JNIenv)
> >>> > >> > > >> >> > > jthread_attach(JNIEnv, jthread) // stores
> >>> JNIEnv and
> >>> > >> Hythread into
> >>> > >> > > >> >> > > TLS, doesn't call vm_attach any longer.
> >>> > >> > > >> >> > > - this is almost what we had from the
> >>> beginning...
> >>> > >> > > >> >> > >
> >>> > >> > > >> >> > > Thanks,
> >>> > >> > > >> >> > > Andrey.
> >>> > >> > > >> >> > >
> >>> > >> > > >> >> > > >
> >>> > >> > > >> >> > > >
> >>> > >> > > >> >> > > > Thanks
> >>> > >> > > >> >> > > > Evgueni
> >>> > >> > > >> >> > > > >
> >>> > >> > > >> >> > > > >
> >>> > >> > > >> >> > > > > Thanks,
> >>> > >> > > >> >> > > > > Andrey.
> >>> > >> > > >> >> > > > >
> >>> > >> > > >> >> > > > > >
> >>> > >> > > >> >> > > > > > Thank you
> >>> > >> > > >> >> > > > > > Evgueni
> >>> > >> > > >> >> > > > > >
> >>> > >> > > >> >> > > > > > On 10/2/06, Evgueni Brevnov
> >>> > >> <ev...@gmail.com>
> >>> > >> > > >> wrote:
> >>> > >> > > >> >> > > > > > > On 9/29/06, Andrey Chernyshev
> >>> > >> <a....@gmail.com>
> >>> > >> > > >> >> wrote:
> >>> > >> > > >> >> > > > > > > > On 9/29/06, Evgueni Brevnov
> >>> > >> <ev...@gmail.com>
> >>> > >> > > >> >> wrote:
> >>> > >> > > >> >> > > > > > > > > Artem,
> >>> > >> > > >> >> > > > > > > > >
> >>> > >> > > >> >> > > > > > > > > Thank you for your feedback....
> >>> find my
> >>> > >> inlined.....
> >>> > >> > > >> >> > > > > > > > >
> >>> > >> > > >> >> > > > > > > > > On 9/29/06, Artem Aliev
> >>> > >> <ar...@gmail.com> wrote:
> >>> > >> > > >> >> > > > > > > > > > Evgueni,
> >>> > >> > > >> >> > > > > > > > > >
> >>> > >> > > >> >> > > > > > > > > > I got most of your changes, but
> >>> still
> >>> > >> disagree
> >>> > >> > > >> with all
> >>> > >> > > >> >> > > > > > > > > > hythread/jthread interface changes.
> >>> > >> Could leave
> >>> > >> > > >> >> interface unchanged.
> >>> > >> > > >> >> > > > > > > > > > See following possible
> >>> solutions, that
> >>> > >> could solve
> >>> > >> > > >> >> the same problems
> >>> > >> > > >> >> > > > > > > > > > without interface changes.
> >>> > >> > > >> >> > > > > > > > > >
> >>> > >> > > >> >> > > > > > > > > >
> >>> > >> > > >> >> > > > > > > > > > 1) daemon attribute is a java
> >>> > >> specific. (Andrey
> >>> > >> > > >> >> mentioned this already).
> >>> > >> > > >> >> > > > > > > > > > Could you please move it back. to
> >>> > >> the jthread
> >>> > >> > > >> >> layer. It is better
> >>> > >> > > >> >> > > > > > > > > > to rename
> >>> > >> > > >> >> > > > > > > > > >
> >>> > >> hythread_wait_for_all_nondaemon_threads() to
> >>> > >> > > >> >> > > > > > > > > >
> >>> jthread_wait_for_all_nondaemon_threads().
> >>> > >> > > >> >> > > > > > > > > Ok, I see no problems to move
> >>> "daemon"
> >>> > >> to java layer.
> >>> > >> > > >> >> In that case:
> >>> > >> > > >> >> > > > > > > > > 1) I will move
> >>> > >> > > >> >> hythread_wait_for_all_nondaemon_threads() from
> >>> > >> > > >> >> > > > > > > > > thread_init.c to one which implements
> >>> > >> java layer.
> >>> > >> > > >> >> > > > > > > > > 2) I will move daemon field from
> >>> > >> HyThread structure.
> >>> > >> > > >> >> > > > > > > > >
> >>> > >> > > >> >> > > > > > > > > Agree?
> >>> > >> > > >> >> > > > > > > >
> >>> > >> > > >> >> > > > > > > > Sounds good to me.
> >>> > >> > > >> >> > > > > > >
> >>> > >> > > >> >> > > > > > > OK, will do that.
> >>> > >> > > >> >> > > > > > >
> >>> > >> > > >> >> > > > > > > >
> >>> > >> > > >> >> > > > > > > >
> >>> > >> > > >> >> > > > > > > > >
> >>> > >> > > >> >> > > > > > > > > >
> >>> > >> > > >> >> > > > > > > > > > 2) JavaVM could be retrieved from
> >>> > >> JNIEnv by
> >>> > >> > > >> >> jni_get_java_vm(). So
> >>> > >> > > >> >> > > > > > > > > > let the jthread_create() and
> >>> others to
> >>> > >> use JNIEnv
> >>> > >> > > >> >> (that is passed from
> >>> > >> > > >> >> > > > > > > > > > java native method).
> >>> > >> > > >> >> > > > > > > > > > The vm_attach could get old JNI env
> >>> > >> and create new
> >>> > >> > > >> >> one for the new thread.
> >>> > >> > > >> >> > > > > > > > > > The first JNIEnv is created in
> >>> > >> CreateVM call and
> >>> > >> > > >> >> could be passed to
> >>> > >> > > >> >> > > > > > > > > > the first thread at startup.
> >>> > >> > > >> >> > > > > > > > > No, no, no. I completely disagree
> >>> with
> >>> > >> that!!! Why do
> >>> > >> > > >> >> you like JNIEnv
> >>> > >> > > >> >> > > > > > > > > but JavaVM. Why do you think that
> >>> > >> passing JavaVM
> >>> > >> > > >> >> instead of JNIEnv
> >>> > >> > > >> >> > > > > > > > > makes TM less modular? I don't see
> >>> any
> >>> > >> difference
> >>> > >> > > >> >> here.... It seems
> >>> > >> > > >> >> > > > > > > > > for me like a big big hack to grab
> >>> > >> JNIEnv from another
> >>> > >> > > >> >> thread and pass
> >>> > >> > > >> >> > > > > > > > > it to jthread_attach to perform
> >>> > >> operations in the
> >>> > >> > > >> >> current thread.
> >>> > >> > > >> >> > > > > > > >
> >>> > >> > > >> >> > > > > > > > TM needs to know JNIEnv, mainly for
> >>> > >> managing the
> >>> > >> > > >> >> references to
> >>> > >> > > >> >> > > > > > > > objects, throwing exceptions and
> >>> calling
> >>> > >> run() method of
> >>> > >> > > >> >> a new thread.
> >>> > >> > > >> >> > > > > > > > JNI spec proposes that JNIEnv is valid
> >>> > >> within the given
> >>> > >> > > >> >> thread, this
> >>> > >> > > >> >> > > > > > > > is why TM holds the JNIEnv pointer
> >>> at the
> >>> > >> moment. This
> >>> > >> > > >> >> is why TM likes
> >>> > >> > > >> >> > > > > > > > the JNIEnv.
> >>> > >> > > >> >> > > > > > > >
> >>> > >> > > >> >> > > > > > > > Having the JNIEnv, one is able to get
> >>> > >> JavaVM but not
> >>> > >> > > >> >> vise versa. This
> >>> > >> > > >> >> > > > > > > > is why TM doesn't like the JavaVM :)
> >>> > >> > > >> >> > > > > > > I see your point. Only one note this
> >>> is true
> >>> > >> for already
> >>> > >> > > >> >> attached threads...
> >>> > >> > > >> >> > > > > > >
> >>> > >> > > >> >> > > > > > > >
> >>> > >> > > >> >> > > > > > > > I agree with you that there is a design
> >>> > >> flaw that the
> >>> > >> > > >> >> JNIEnv is copied
> >>> > >> > > >> >> > > > > > > > from the parent thread to a child
> >>> thread
> >>> > >> during thread
> >>> > >> > > >> >> creation. I
> >>> > >> > > >> >> > > > > > > > think it could be resolved via
> >>> vm_attach()
> >>> > >> hook - with
> >>> > >> > > >> >> this event, VM
> >>> > >> > > >> >> > > > > > > > might tell the TM what the JNIEnv
> >>> pointer
> >>> > >> for new thread
> >>> > >> > > >> >> should be. I
> >>> > >> > > >> >> > > > > > > > think you did that by extending the
> >>> > >> vm_attach() call
> >>> > >> > > >> >> with the JNIEnv**
> >>> > >> > > >> >> > > > > > > > argument.
> >>> > >> > > >> >> > > > > > > >
> >>> > >> > > >> >> > > > > > > > What is not completely clear is, why do
> >>> > >> you have to pass
> >>> > >> > > >> >> the JavaVM
> >>> > >> > > >> >> > > > > > > > forth and back, once from VM to TM, and
> >>> > >> then back from
> >>> > >> > > >> >> TM to VM again?
> >>> > >> > > >> >> > > > > > > >
> >>> > >> > > >> >> > > > > > > > If you need to know in jthread_attach,
> >>> > >> which particular
> >>> > >> > > >> >> VM vm_attach()
> >>> > >> > > >> >> > > > > > > > event is coming from, you could have
> >>> > >> vm_attach like
> >>> > >> > > >> >> > > > > > > > vm_attach(JNIEnv* currentThreadEnv,
> >>> JNIEnv**
> >>> > >> > > >> >> newThreadEnv).
> >>> > >> > > >> >> > > > > > > I'm a little bit confused.....Current
> >>> thread
> >>> > >> hasn't been
> >>> > >> > > >> >> attached yet.
> >>> > >> > > >> >> > > > > > > So there is no JNIEnv for it yet. How
> >>> it can
> >>> > >> be passed as
> >>> > >> > > >> >> the first
> >>> > >> > > >> >> > > > > > > parameter to vm_attach()?
> >>> > >> > > >> >> > > > > > >
> >>> > >> > > >> >> > > > > > > > Then you will be always able to get the
> >>> > >> JavaVM from the
> >>> > >> > > >> >> JNIEnv.
> >>> > >> > > >> >> > > > > > > > The only difference is that you are
> >>> > >> currently doing
> >>> > >> > > >> >> JNIEnv->JavaVM
> >>> > >> > > >> >> > > > > > > > conversion in the VMThreadManager,
> >>> but why
> >>> > >> can't you
> >>> > >> > > >> >> just do this in
> >>> > >> > > >> >> > > > > > > > vm_attach() without changing the
> >>> interface
> >>> > >> of the TM?
> >>> > >> > > >> >> > > > > > > > So far JavaVM really looks like an
> >>> extra
> >>> > >> knowledge that
> >>> > >> > > >> >> TM doesn't
> >>> > >> > > >> >> > > > > > > > have to be aware of.
> >>> > >> > > >> >> > > > > > > >
> >>> > >> > > >> >> > > > > > > > > Moreover there is no JNIEnv when main
> >>> > >> thread attaches
> >>> > >> > > >> >> to VM. So we
> >>> > >> > > >> >> > > > > > > > > should either keep it as is or change
> >>> > >> original design
> >>> > >> > > >> >> of TM and attach
> >>> > >> > > >> >> > > > > > > > > thread to VM before attaching it
> >>> to TM.
> >>> > >> In that case
> >>> > >> > > >> >> we will have
> >>> > >> > > >> >> > > > > > > > > valid JNIEnv which can be passed to
> >>> > >> jthread_atatch. We
> >>> > >> > > >> >> need to think
> >>> > >> > > >> >> > > > > > > > > over it twice before changing
> >>> something....
> >>> > >> > > >> >> > > > > > > >
> >>> > >> > > >> >> > > > > > > > Right. For jthread_attach, JNIenv
> >>> needs to
> >>> > >> be changed
> >>> > >> > > >> >> from being input
> >>> > >> > > >> >> > > > > > > > parameter to being the output
> >>> parameter.
> >>> > >> The way how
> >>> > >> > > >> >> JNIenv is
> >>> > >> > > >> >> > > > > > > > obtained by TM should be vm_attach()
> >>> event.
> >>> > >> > > >> >> > > > > > > OK, JNIEnv is output parameter. And it
> >>> > >> obtained by
> >>> > >> > > >> >> vm_attach(). This
> >>> > >> > > >> >> > > > > > > is exactly like I do in the patch. What I
> >>> > >> don't understand
> >>> > >> > > >> >> is how
> >>> > >> > > >> >> > > > > > > jthread_attach knows to which VM the
> >>> thread
> >>> > >> should be
> >>> > >> > > >> >> attached? Do you
> >>> > >> > > >> >> > > > > > > suggest calling vm_attach first to create
> >>> > >> JNIEnv it pass
> >>> > >> > > >> >> it to
> >>> > >> > > >> >> > > > > > > jthread_attach?
> >>> > >> > > >> >> > > > > > >
> >>> > >> > > >> >> > > > > > > >
> >>> > >> > > >> >> > > > > > > > >
> >>> > >> > > >> >> > > > > > > > >
> >>> > >> > > >> >> > > > > > > > >
> >>> > >> > > >> >> > > > > > > > > >
> >>> > >> > > >> >> > > > > > > > > >
> >>> > >> > > >> >> > > > > > > > > > 4) Original classlib hythread do
> >>> not use
> >>> > >> > > >> >> hythread_library_t in arguments,
> >>> > >> > > >> >> > > > > > > > > > It uses following code:
> >>> > >> > > >> >> > > > > > > > > >
> >>> > >> > > >> >> > > > > > > > > > hythread_library_t lib =
> >>> GLOBAL_DATA
> >>> > >> > > >> >> (default_library);
> >>> > >> > > >> >> > > > > > > > > > or
> >>> > >> > > >> >> > > > > > > > > > hythread_library_t library =
> >>> thread-
> >>> > >> >library;
> >>> > >> > > >> >> > > > > > > > > >
> >>> > >> > > >> >> > > > > > > > > > So could you please use the same
> >>> > >> mechanism and
> >>> > >> > > >> >> remove hythread_*_ex >functions.
> >>> > >> > > >> >> > > > > > > > > Let's see if classlib's hythread
> >>> needs
> >>> > >> changing first.
> >>> > >> > > >> >> It seems for me
> >>> > >> > > >> >> > > > > > > > > such code prevents us from having
> >>> multi VM.
> >>> > >> > > >> >> > > > > > > > >
> >>> > >> > > >> >> > > > > > > > > >
> >>> > >> > > >> >> > > > > > > > > > 5. You introduce more then one jni
> >>> > >> env, but still
> >>> > >> > > >> >> use global variable for it.
> >>> > >> > > >> >> > > > > > > > > > So all changes like following:
> >>> > >> > > >> >> > > > > > > > > > - JNIEnv *jenv = (JNIEnv*)
> >>> > >> jni_native_intf;
> >>> > >> > > >> >> > > > > > > > > > + JNIEnv *jenv =
> >>> jni_native_intf;
> >>> > >> > > >> >> > > > > > > > > >
> >>> > >> > > >> >> > > > > > > > > > should be like:
> >>> > >> > > >> >> > > > > > > > > > - JNIEnv *jenv = (JNIEnv*)
> >>> > >> jni_native_intf;
> >>> > >> > > >> >> > > > > > > > > > + JNIEnv *jenv = get_jni_env
> >>> > >> (jthread_self());
> >>> > >> > > >> >> > > > > > > > >
> >>> > >> > > >> >> > > > > > > > > Ok, I see. I agree that global
> >>> > >> jni_native_intf should
> >>> > >> > > >> >> not be used.
> >>> > >> > > >> >> > > > > > > > > There was simple reason why I altered
> >>> > >> such lines.
> >>> > >> > > >> >> Because I changed
> >>> > >> > > >> >> > > > > > > > > the type of jni_native_intf and no
> >>> > >> casting operator
> >>> > >> > > >> >> is needed now. To
> >>> > >> > > >> >> > > > > > > > > be honest I think get_jni_env
> >>> > >> (jthread_self()) can be
> >>> > >> > > >> >> good as temporary
> >>> > >> > > >> >> > > > > > > > > solution only. Lets wait for
> >>> design of
> >>> > >> multi VM and
> >>> > >> > > >> >> fix it according
> >>> > >> > > >> >> > > > > > > > > to it.
> >>> > >> > > >> >> > > > > > > >
> >>> > >> > > >> >> > > > > > > > While we are in JNI code, we always
> >>> have
> >>> > >> the JNIenv (at
> >>> > >> > > >> >> least
> >>> > >> > > >> >> > > > > > > > initially it comes from Java code).
> >>> If we
> >>> > >> consider VM
> >>> > >> > > >> >> code as if it
> >>> > >> > > >> >> > > > > > > > was a JNI application, then it seems
> >>> like
> >>> > >> we should be
> >>> > >> > > >> >> just passing
> >>> > >> > > >> >> > > > > > > > JNIEnv as a parameter to all
> >>> functions in
> >>> > >> VM. Or, we can
> >>> > >> > > >> >> be taking it
> >>> > >> > > >> >> > > > > > > > from TLS (via jthread_self()),
> >>> depending
> >>> > >> on which way is
> >>> > >> > > >> >> faster...
> >>> > >> > > >> >> > > > > > > Agree.
> >>> > >> > > >> >> > > > > > >
> >>> > >> > > >> >> > > > > > > >
> >>> > >> > > >> >> > > > > > > > >
> >>> > >> > > >> >> > > > > > > > > >
> >>> > >> > > >> >> > > > > > > > > > 6). And small remarks:
> >>> > >> > > >> >> > > > > > > > > > +jint vm_init1(JavaVM_Internal *
> >>> java_vm,
> >>> > >> > > >> >> JavaVMInitArgs * vm_arguments);
> >>> > >> > > >> >> > > > > > > > > > +jint vm_init2(JNIEnv_Internal *
> >>> > >> jni_env);
> >>> > >> > > >> >> > > > > > > > > > Could you make names more
> >>> meaningful,
> >>> > >> then 1,2,3...?
> >>> > >> > > >> >> > > > > > > > > Ok, will do that.
> >>> > >> > > >> >> > > > > > > > >
> >>> > >> > > >> >> > > > > > > > > >
> >>> > >> > > >> >> > > > > > > > > > class VM_thread {
> >>> > >> > > >> >> > > > > > > > > > ...
> >>> > >> > > >> >> > > > > > > > > > + JNIEnv_Internal * jni_env;
> >>> > >> > > >> >> > > > > > > > > > The jthread already has the jni_env
> >>> > >> pointer, you do
> >>> > >> > > >> >> not need to
> >>> > >> > > >> >> > > > > > > > > > duplicate it here.
> >>> > >> > > >> >> > > > > > > > > > forexample by using
> >>> > >> > > >> >> jthread_get_JNI_env(jthread_self());
> >>> > >> > > >> >> > > > > > > > >
> >>> > >> > > >> >> > > > > > > > > Yes I know. I don't see any problems
> >>> > >> here. Some times
> >>> > >> > > >> >> it is much more
> >>> > >> > > >> >> > > > > > > > > convenient to get JNIEnv from
> >>> VM_thread
> >>> > >> structure (and
> >>> > >> > > >> >> faster) instead
> >>> > >> > > >> >> > > > > > > > > of doing jthread_get_JNI_env
> >>> (jthread_self
> >>> > >> ()). So I
> >>> > >> > > >> >> need strong
> >>> > >> > > >> >> > > > > > > > > arguments for removing it. Again it
> >>> > >> seems that should
> >>> > >> > > >> >> be addressed in
> >>> > >> > > >> >> > > > > > > > > design of multi VM. So lets forget
> >>> about
> >>> > >> it for a
> >>> > >> > > >> >> while...
> >>> > >> > > >> >> > > > > > > >
> >>> > >> > > >> >> > > > > > > > I think that the data duplication would
> >>> > >> always serve as
> >>> > >> > > >> >> a potential
> >>> > >> > > >> >> > > > > > > > source of errors - while updating
> >>> one copy
> >>> > >> of object,
> >>> > >> > > >> >> you may forget
> >>> > >> > > >> >> > > > > > > > to update the other, often resulting
> >>> into
> >>> > >> a strange
> >>> > >> > > >> >> behavior of the
> >>> > >> > > >> >> > > > > > > > whole application. Let's see what
> >>> are the
> >>> > >> specific
> >>> > >> > > >> >> performance
> >>> > >> > > >> >> > > > > > > > concerns that have to be addressed.
> >>> To get
> >>> > >> VM_thread
> >>> > >> > > >> >> structure, you
> >>> > >> > > >> >> > > > > > > > would eventually go to the TLS, just
> >>> like
> >>> > >> > > >> >> > > > > > > > jthread_get_JNI_env(jthread_self()
> >>> would do.
> >>> > >> > > >> >> > > > > > > If there is already VM_thread
> >>> structure for
> >>> > >> some reasons
> >>> > >> > > >> >> then there
> >>> > >> > > >> >> > > > > > > will be no extra access to TLS. It is
> >>> > >> definitely much
> >>> > >> > > >> more in
> >>> > >> > > >> >> > > > > > > jthread_get_JNI_env(jthread_self()
> >>> than just
> >>> > >> one TLS
> >>> > >> > > >> >> access and one
> >>> > >> > > >> >> > > > > > > dereferncing. I don't think it is a
> >>> really
> >>> > >> big problem
> >>> > >> > > >> >> now. Do you
> >>> > >> > > >> >> > > > > > > agree to look at this later. I guess
> >>> multi VM
> >>> > >> > > >> >> implementation will
> >>> > >> > > >> >> > > > > > > alter it in any case.
> >>> > >> > > >> >> > > > > > >
> >>> > >> > > >> >> > > > > > > Thanks
> >>> > >> > > >> >> > > > > > > Evgueni
> >>> > >> > > >> >> > > > > > >
> >>> > >> > > >> >> > > > > > > >
> >>> > >> > > >> >> > > > > > > > Thanks,
> >>> > >> > > >> >> > > > > > > > Andrey.
> >>> > >> > > >> >> > > > > > > >
> >>> > >> > > >> >> > > > > > > > >
> >>> > >> > > >> >> > > > > > > > > Evgueni
> >>> > >> > > >> >> > > > > > > > > >
> >>> > >> > > >> >> > > > > > > > > > Thanks
> >>> > >> > > >> >> > > > > > > > > > Artem
> >>> > >> > > >> >> > > > > > > > > >
> >>> > >> > > >> >> > > > > > > > > > On 9/28/06, Evgueni Brevnov
> >>> > >> > > >> >> <ev...@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.
> >>> > >> > > >> >> > > > > > > > > > >
> >>> > >> > > >> >> > > > > > > > > > > Thanks
> >>> > >> > > >> >> > > > > > > > > > > Evgueni
> >>> > >> > > >> >> > > > > > > > > > >
> >>> > >> > > >> >> > > > > > > > > > > On 9/28/06, Geir Magnusson Jr.
> >>> > >> <ge...@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
> >>> > >> > > >> >> <we...@gmail.com> wrote:
> >>> > >> > > >> >> > > > > > > > > > > > >> On 9/26/06, Evgueni Brevnov
> >>> > >> > > >> >> <ev...@gmail.com> wrote:
> >>> > >> > > >> >> > > > > > > > > > > > >> >
> >>> > >> > > >> >> > > > > > > > > > > > >> > On 9/27/06, Andrey
> >>> Chernyshev
> >>> > >> > > >> >> <a....@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
> >>> > >> > > >> >> > > > > > > > > > >
> >>> > >> > > >> >> > > > > > > > > > >
> >>> > >> > > >> >> > > > > > > > > >
> >>> > >> > > >> >> > > > > > > > > >
> >>> > >> > > >> >>
> >>> > >>
> >>> --------------------------------------------------------------------
> >>> -
> >>> > >> > > >> >> > > > > > > > > > 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
> >>> > >> > > >> >> > > > > > > > >
> >>> > >> > > >> >> > > > > > > > >
> >>> > >> > > >> >> > > > > > > >
> >>> > >> > > >> >> > > > > > > >
> >>> > >> > > >> >> > > > > > > > --
> >>> > >> > > >> >> > > > > > > > Andrey Chernyshev
> >>> > >> > > >> >> > > > > > > > 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
> >>> > >> > > >> >> > > > > >
> >>> > >> > > >> >> > > > > >
> >>> > >> > > >> >> > > > >
> >>> > >> > > >> >> > > > >
> >>> > >> > > >> >> > > > > --
> >>> > >> > > >> >> > > > > Andrey Chernyshev
> >>> > >> > > >> >> > > > > 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
> >>> > >> > > >> >> > > >
> >>> > >> > > >> >> > > >
> >>> > >> > > >> >> > >
> >>> > >> > > >> >> > >
> >>> > >> > > >> >> > > --
> >>> > >> > > >> >> > > Andrey Chernyshev
> >>> > >> > > >> >> > > 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
> >>> > >> > > >>
> >>> > >> > > >>
> >>> > >> > > >
> >>> > >> > > >
> >>> > >>
> >>> --------------------------------------------------------------------
> >>> -
> >>> > >> > > > 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
> >>> > >
> >>> >
> >>> >
> >>> >
> >>> --------------------------------------------------------------------
> >>> -
> >>> > 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
> >
>
>
> ---------------------------------------------------------------------
> 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
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
btw, why are there so many warnings? I'm not comfortable with having
to suppress them - I'd rather fix them...
On Oct 9, 2006, at 9:49 AM, Geir Magnusson Jr. wrote:
> sure - I'll redo the whole thing from clean...
>
>
> On Oct 9, 2006, at 9:45 AM, Evgueni Brevnov wrote:
>
>> BTW, could you verify the right patch for tests was used? It
>> should be
>> tests.final.2.patch...... Sorry for the mess with patches....
>>
>> Evgueni
>>
>> On 10/9/06, Evgueni Brevnov <ev...@gmail.com> wrote:
>>> I put debug printing into test_ti_instrum.c and attached it to JIRA.
>>> Could you run it on your machine and send me console output.
>>>
>>> Evgueni
>>>
>>> On 10/9/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>>> > I keep getting a failure when running the tests -
>>> >
>>> > test_jthread_get_all-threads failling the assertion at
>>> > test_ti_instrum.c:80
>>> >
>>> > geir
>>> >
>>> > On Oct 8, 2006, at 7:19 AM, Evgueni Brevnov wrote:
>>> >
>>> > > While running cunit on Linux it turned out one test case
>>> fails some
>>> > > time. The fix is in tests.final.2.patch.
>>> > >
>>> > > So the last versions to be committed:
>>> > > invocation_api.final.patch
>>> > > build.final.2.patch
>>> > > tests.final.2.patch
>>> > >
>>> > > Evgueni
>>> > >
>>> > >
>>> > > On 10/8/06, Evgueni Brevnov <ev...@gmail.com> wrote:
>>> > >> I mahaged to resolve the problem on Linux.... will update
>>> > >> build.final.patch with build.final.2.patch in a while
>>> > >>
>>> > >> On 10/8/06, Evgueni Brevnov <ev...@gmail.com> wrote:
>>> > >> > Hi,
>>> > >> >
>>> > >> > Oh! Ooh! I did that..... I passed cunit, somke, kernel
>>> tests on
>>> > >> > Windows and smoke, kernel tests on Linux. Unfortunately I
>>> failed to
>>> > >> > link cunit tests on Linux so far. So I disabled cunit on
>>> Linux
>>> > >> until
>>> > >> > the problem is solved. I believe it is acceptable as short
>>> term
>>> > >> > solution. I found several problems in cunit tests. I will
>>> come
>>> > >> up with
>>> > >> > my findings later (not today).
>>> > >> >
>>> > >> > Use latest patches from HARMONY-1582. They are marked as
>>> final.
>>> > >> There
>>> > >> > are three patches. One for build module, one for cunit
>>> tests and
>>> > >> one
>>> > >> > for VM itself.
>>> > >> >
>>> > >> > Thanks
>>> > >> > Evgueni
>>> > >> >
>>> > >> >
>>> > >> > On 10/6/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>>> > >> > > Nooooooo! LOL
>>> > >> > >
>>> > >> > > I'm here waiting - This will unblock a whole bunch of
>>> things :)
>>> > >> > >
>>> > >> > > Thanks for the effort
>>> > >> > >
>>> > >> > > Evgueni Brevnov wrote:
>>> > >> > > > Geir,
>>> > >> > > >
>>> > >> > > > That's terrible. We have power outage....servers are
>>> down. I
>>> > >> can't
>>> > >> > > > send the patches now.... will do it tomorrow
>>> > >> > > >
>>> > >> > > > Evgueni
>>> > >> > > > On 10/5/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>>> > >> > > >> woo hoo! here we go...
>>> > >> > > >>
>>> > >> > > >>
>>> > >> > > >> Andrey Chernyshev wrote:
>>> > >> > > >> > Hi Evgueni,
>>> > >> > > >> >
>>> > >> > > >> > On 10/4/06, Evgueni Brevnov
>>> <ev...@gmail.com>
>>> > >> wrote:
>>> > >> > > >> >> Hi All,
>>> > >> > > >> >>
>>> > >> > > >> >> I have attached updated patch to the JIRA. It should
>>> > >> resolve remain
>>> > >> > > >> >> concerns. Andrey, could you give a green light now?
>>> > >> > > >> >
>>> > >> > > >> > Thanks for updating the patch! I agree it it can be
>>> > >> committed, at
>>> > >> > > >> > least signatures look good. 5 revisions seem like more
>>> > >> than enough :).
>>> > >> > > >> > Anyways, I think the remaining issues can be resolved
>>> > >> with additional
>>> > >> > > >> > patches. Thanks again for the good work and your
>>> patience.
>>> > >> > > >> >
>>> > >> > > >> > Thanks,
>>> > >> > > >> > Andrey.
>>> > >> > > >> >
>>> > >> > > >> >>
>>> > >> > > >> >> Thanks
>>> > >> > > >> >> Evgueni
>>> > >> > > >> >>
>>> > >> > > >> >> On 10/4/06, Evgueni Brevnov
>>> <ev...@gmail.com>
>>> > >> wrote:
>>> > >> > > >> >> > Andrey,
>>> > >> > > >> >> >
>>> > >> > > >> >> > I see your points. I think both approaches have
>>> > >> advantages and
>>> > >> > > >> >> > disadvantages. I think it is quite hard to say
>>> which
>>> > >> approach is
>>> > >> > > >> >> > better until we play with one VM only. I still feel
>>> > >> like introducing
>>> > >> > > >> >> > one more dependence is better than spreading code
>>> > >> which deals with
>>> > >> > > >> >> > attachment among VM and TM. We really get stuck.
>>> OK,
>>> > >> just because I
>>> > >> > > >> >> > want to move forward I will do required changes
>>> to remove
>>> > >> > > >> >> > vm_create_jthread from TM. I believe that will
>>> resolve
>>> > >> all our
>>> > >> > > >> >> > disagreements and the patch will be applied soon.
>>> > >> > > >> >> >
>>> > >> > > >> >> >
>>> > >> > > >> >> > Thanks
>>> > >> > > >> >> > Evgueni.
>>> > >> > > >> >> >
>>> > >> > > >> >> > On 10/4/06, Andrey Chernyshev
>>> > >> <a....@gmail.com> wrote:
>>> > >> > > >> >> > > On 10/3/06, Evgueni Brevnov
>>> > >> <ev...@gmail.com> wrote:
>>> > >> > > >> >> > > > On 10/3/06, Andrey Chernyshev
>>> > >> <a....@gmail.com> wrote:
>>> > >> > > >> >> > > > > On 10/2/06, Evgueni Brevnov
>>> > >> <ev...@gmail.com> wrote:
>>> > >> > > >> >> > > > > > Andrey,
>>> > >> > > >> >> > > > > >
>>> > >> > > >> >> > > > > > Just to be clear.... I agree with you it
>>> is more
>>> > >> > > >> convenient if
>>> > >> > > >> >> > > > > > jthread_create takes JNIEnv instead of
>>> JavaVM. It
>>> > >> > > >> reflects that
>>> > >> > > >> >> > > > > > current thread has been attached
>>> already. Do
>>> > >> you think it
>>> > >> > > >> >> makes sense
>>> > >> > > >> >> > > > > > to get rid of JNIEnv and use
>>> > >> jthread_get_JNI_env in that
>>> > >> > > >> case?
>>> > >> > > >> >> > > > >
>>> > >> > > >> >> > > > > The jthread_* layer is designed like if it
>>> were
>>> > >> a regular JNI
>>> > >> > > >> >> > > > > application which is meant to be called
>>> from the
>>> > >> Java code,
>>> > >> > > >> hence
>>> > >> > > >> >> > > > > every function on that layer receives
>>> JNIenv. We
>>> > >> can probably
>>> > >> > > >> >> get rid
>>> > >> > > >> >> > > > > of the JNEnv parameter for jthread_*
>>> functions,
>>> > >> assuming that
>>> > >> > > >> >> TM can
>>> > >> > > >> >> > > > > always extract JNIenv for the current
>>> thread with
>>> > >> > > >> >> > > > > jthread_get_JNI_env().
>>> > >> > > >> >> > > > > My only concern would be the performance
>>> - once
>>> > >> the JNIenv is
>>> > >> > > >> >> already
>>> > >> > > >> >> > > > > known for the native part of the kernel
>>> classes
>>> > >> impl, it
>>> > >> > > >> must be
>>> > >> > > >> >> > > > > cheaper to pass JNIEnv to TM as an extra
>>> > >> parameter rather than
>>> > >> > > >> >> extract
>>> > >> > > >> >> > > > > it from the TLS again.
>>> > >> > > >> >> > > > > Other than that, I see no strong
>>> advantages in
>>> > >> keeping JNIEnv
>>> > >> > > >> >> parameter.
>>> > >> > > >> >> > > > >
>>> > >> > > >> >> > > > >
>>> > >> > > >> >> > > > > > Regarding jthread_attach. I still didn't
>>> get
>>> > >> your point....
>>> > >> > > >> >> Clarify it
>>> > >> > > >> >> > > > > > please if you think jhread_attach should be
>>> > >> modified.
>>> > >> > > >> >> > > > >
>>> > >> > > >> >> > > > > Sorry for being not clear: I think for
>>> > >> jthread_attach, we have
>>> > >> > > >> >> two options:
>>> > >> > > >> >> > > > > 1) Make JNIEnv input parameter - it must
>>> be new
>>> > >> JNIEnv that VM
>>> > >> > > >> >> > > > > pre-allocates for the new Java thread.
>>> > >> jthread_attach
>>> > >> > > >> would just
>>> > >> > > >> >> > > > > associate it with the current thread.
>>> > >> > > >> >> > > > >
>>> > >> > > >> >> > > > > 2) Obtain JNIEnv via vm_attach() callback. In
>>> > >> this case, if
>>> > >> > > >> >> > > > > vm_attach() callback implementation needs to
>>> > >> know for which
>>> > >> > > >> >> JavaVM new
>>> > >> > > >> >> > > > > JNIenv has to be allocated, then we'll
>>> need to
>>> > >> add JavaVM as
>>> > >> > > >> >> input
>>> > >> > > >> >> > > > > parameter for jthread_attach().
>>> > >> > > >> >> > > > > I think both options should be fine, (1)
>>> would
>>> > >> probably
>>> > >> > > >> keep TM
>>> > >> > > >> >> > > > > interface a bit lighter, though (2) may look
>>> > >> more closer to
>>> > >> > > >> >> the JNI
>>> > >> > > >> >> > > > > invocation API idea.
>>> > >> > > >> >> > > > > So I think adding JavaVM specifically for
>>> > >> jthread_attach
>>> > >> > > >> may make
>>> > >> > > >> >> > > > > sense given the explanation you provided
>>> earlier.
>>> > >> > > >> >> > > > >
>>> > >> > > >> >> > > > > The concern I would have regarding the
>>> proposed
>>> > >> jthread_attach
>>> > >> > > >> >> > > > > implementation is a call to
>>> vm_create_jthread()
>>> > >> - this call
>>> > >> > > >> >> introduces
>>> > >> > > >> >> > > > > an extra dependency of TM on vmcore that I'd
>>> > >> prefer to be
>>> > >> > > >> >> avoided. In
>>> > >> > > >> >> > > > > the original version, jthread_attach() was
>>> > >> taking jthread
>>> > >> > > >> >> argument of
>>> > >> > > >> >> > > > > the already prepared j.l.Thread.
>>> > >> > > >> >> > > >
>>> > >> > > >> >> > > > I understand your concern. Unfortunately I
>>> don't
>>> > >> see what we
>>> > >> > > >> can do
>>> > >> > > >> >> > > > here. Let me explain. In the beginning you
>>> have an
>>> > >> unattached
>>> > >> > > >> >> native
>>> > >> > > >> >> > > > thread. To be able to call java code (which is
>>> > >> required for
>>> > >> > > >> >> > > > constructing j.l.Thread instance) the thread
>>> > >> should be attached
>>> > >> > > >> >> first.
>>> > >> > > >> >> > > > To be specific it should be attached to VM by
>>> > >> calling vm_attach
>>> > >> > > >> >> which
>>> > >> > > >> >> > > > will return a valid JNIEnv It is valid to
>>> use JNI
>>> > >> from that
>>> > >> > > >> moment.
>>> > >> > > >> >> > > > Obtained JNIEnv can be used to execute java
>>> code
>>> > >> and create
>>> > >> > > >> >> j.l.Thread
>>> > >> > > >> >> > > > instance. Since we do vm_attach in
>>> jthread_attach
>>> > >> we need to do
>>> > >> > > >> >> > > > vm_create_jthread inside jthread_atach as well.
>>> > >> > > >> >> > > > Of course it can be an alternative to do
>>> vm_attach
>>> > >> and
>>> > >> > > >> >> > > > vm_create_jthread outside of TM right before
>>> > >> jthread_attach.
>>> > >> > > >> >> Sure it
>>> > >> > > >> >> > > > will reduce one dependence between VM and
>>> TM. But
>>> > >> it seems like
>>> > >> > > >> >> > > > artificial action for me just because of
>>> > >> dependency....
>>> > >> > > >> >> > >
>>> > >> > > >> >> > > Why do you think it is artificial? I would rather
>>> > >> prefer not to
>>> > >> > > >> throw
>>> > >> > > >> >> > > vm_attach event from the jthread_attach() call at
>>> > >> all than to add
>>> > >> > > >> >> > > extra dependency. The idea of jthread layer is a
>>> > >> Java face to
>>> > >> > > >> >> > > hythread, it is meant to know either a little or
>>> > >> nothing about the
>>> > >> > > >> >> > > rest of VM. It may be logical to throw vm_attach
>>> > >> call from the
>>> > >> > > >> newly
>>> > >> > > >> >> > > created thread, because there is no other way
>>> to let
>>> > >> know VM
>>> > >> > > >> the new
>>> > >> > > >> >> > > thread is created. VM attach is a different
>>> case -
>>> > >> VM already
>>> > >> > > >> knows
>>> > >> > > >> >> > > about new Java thread at the time of the
>>> > >> AttachCurrentThread call.
>>> > >> > > >> >> > >
>>> > >> > > >> >> > > >
>>> > >> > > >> >> > > > > Do you think it makes sense to replace a
>>> single
>>> > >> jthread
>>> > >> > > >> >> parameter with
>>> > >> > > >> >> > > > > a variety of stuff (like thread group,
>>> name)? It
>>> > >> seems the
>>> > >> > > >> only
>>> > >> > > >> >> > > > > purpose of at these args is to be passed
>>> back to
>>> > >> VM for
>>> > >> > > >> >> > > > > vm_jthread_create(). I would suggest to
>>> change
>>> > >> this and try
>>> > >> > > >> doing
>>> > >> > > >> >> > > > > either of:
>>> > >> > > >> >> > > > > 1) Make signature of jthread_attach with 3
>>> args,
>>> > >> JavaVM,
>>> > >> > > >> >> jthread and the daemon.
>>> > >> > > >> >> > > > Why do you want to pass daemon to TM but
>>> thread's
>>> > >> name and
>>> > >> > > >> >> group. Just
>>> > >> > > >> >> > > > because current TM doesn't need such
>>> information?
>>> > >> What if it is
>>> > >> > > >> >> > > > required to get thread name later? Say by
>>> introducing
>>> > >> > > >> >> > >
>>> > >> > > >> >> > > I imagine you need a daemon attribute since
>>> the TM
>>> > >> is still
>>> > >> > > >> managing
>>> > >> > > >> >> > > the thread daemonality. TM is not managing thread
>>> > >> name and group -
>>> > >> > > >> >> > > they are all kept on the Java level, hence
>>> passing
>>> > >> them may be
>>> > >> > > >> >> > > excessive.
>>> > >> > > >> >> > >
>>> > >> > > >> >> > > > jthread_get_name... What will you do in that
>>> case?
>>> > >> Let me
>>> > >> > > >> guess you
>>> > >> > > >> >> > > > will call j.l.Thread.getName. Right. Ok! In
>>> that
>>> > >> case I see no
>>> > >> > > >> >> > > > problems to call j.l.Thread.isDaemon. Do you
>>> > >> agree? So it
>>> > >> > > >> doesn't
>>> > >> > > >> >> > >
>>> > >> > > >> >> > > As I suggested earlier, the best way to handle
>>> > >> daemonality would
>>> > >> > > >> >> > > probably be in pure Java - in j.l.Thread (or
>>> > >> > > >> j.l.VMThreadManager) or
>>> > >> > > >> >> > > whatever. You already lifted it up to the jthread
>>> > >> level, but
>>> > >> > > >> what if
>>> > >> > > >> >> > > we can go a little bit higher...
>>> > >> > > >> >> > >
>>> > >> > > >> >> > > > seems to be a good design to pass only part
>>> of the
>>> > >> > > >> information to
>>> > >> > > >> >> > > > jthread_atach. Lets look at the signature of
>>> > >> > > >> >> AttachCurrentThread. It
>>> > >> > > >> >> > > > takes exactly these three parameters (daemon,
>>> > >> name, group)
>>> > >> > > >> >> passed as a
>>> > >> > > >> >> > > > structure. I was thinking about having
>>> exactly the
>>> > >> same
>>> > >> > > >> >> structure as
>>> > >> > > >> >> > > > third parameter of jthread_attach but it
>>> occured
>>> > >> to be more
>>> > >> > > >> >> convinient
>>> > >> > > >> >> > > > to pass them seperatly. Although I don't see
>>> > >> strong reasons
>>> > >> > > >> against
>>> > >> > > >> >> > > > having a structure a third parameter.
>>> > >> > > >> >> > >
>>> > >> > > >> >> > > I see. Acually, I would love to keep the
>>> > >> jthread_attach func-ty at
>>> > >> > > >> >> the
>>> > >> > > >> >> > > minimum level which will be needed to handle the
>>> > >> only data that TM
>>> > >> > > >> >> > > should be aware of. We need a formal boundary
>>> > >> between jthread
>>> > >> > > >> layer
>>> > >> > > >> >> > > and vmcore (otherwise jthread won't have a
>>> much of
>>> > >> sense, one may
>>> > >> > > >> >> > > consider it just as a convenience set of
>>> functions
>>> > >> in vmcore which
>>> > >> > > >> >> are
>>> > >> > > >> >> > > doing something with threading).
>>> > >> > > >> >> > >
>>> > >> > > >> >> > > >
>>> > >> > > >> >> > > > > 2) Move the implementation of
>>> vm_create_jtrhead
>>> > >> () to
>>> > >> > > >> >> > > > > thread_java_basic.c - could it be written in
>>> > >> pure JNI without
>>> > >> > > >> >> using
>>> > >> > > >> >> > > > > internal VM API like class_alloc_new_object
>>> ()?
>>> > >> > > >> >> > > >
>>> > >> > > >> >> > > > Yes, this can be done but it doesn't fix the
>>> > >> problem. You still
>>> > >> > > >> >> need
>>> > >> > > >> >> > > > to know about internal constructor of
>>> j.l.Thread
>>> > >> > > >> >> > >
>>> > >> > > >> >> > > That's bad. Given what you said, now it seems
>>> that
>>> > >> the most
>>> > >> > > >> >> preferable
>>> > >> > > >> >> > > sequence for AttachCurrentThread impl still
>>> would be
>>> > >> like:
>>> > >> > > >> >> > > JNIEnv = vm_attach();
>>> > >> > > >> >> > > jthread = create_jthread(JNIenv)
>>> > >> > > >> >> > > jthread_attach(JNIEnv, jthread) // stores
>>> JNIEnv and
>>> > >> Hythread into
>>> > >> > > >> >> > > TLS, doesn't call vm_attach any longer.
>>> > >> > > >> >> > > - this is almost what we had from the
>>> beginning...
>>> > >> > > >> >> > >
>>> > >> > > >> >> > > Thanks,
>>> > >> > > >> >> > > Andrey.
>>> > >> > > >> >> > >
>>> > >> > > >> >> > > >
>>> > >> > > >> >> > > >
>>> > >> > > >> >> > > > Thanks
>>> > >> > > >> >> > > > Evgueni
>>> > >> > > >> >> > > > >
>>> > >> > > >> >> > > > >
>>> > >> > > >> >> > > > > Thanks,
>>> > >> > > >> >> > > > > Andrey.
>>> > >> > > >> >> > > > >
>>> > >> > > >> >> > > > > >
>>> > >> > > >> >> > > > > > Thank you
>>> > >> > > >> >> > > > > > Evgueni
>>> > >> > > >> >> > > > > >
>>> > >> > > >> >> > > > > > On 10/2/06, Evgueni Brevnov
>>> > >> <ev...@gmail.com>
>>> > >> > > >> wrote:
>>> > >> > > >> >> > > > > > > On 9/29/06, Andrey Chernyshev
>>> > >> <a....@gmail.com>
>>> > >> > > >> >> wrote:
>>> > >> > > >> >> > > > > > > > On 9/29/06, Evgueni Brevnov
>>> > >> <ev...@gmail.com>
>>> > >> > > >> >> wrote:
>>> > >> > > >> >> > > > > > > > > Artem,
>>> > >> > > >> >> > > > > > > > >
>>> > >> > > >> >> > > > > > > > > Thank you for your feedback....
>>> find my
>>> > >> inlined.....
>>> > >> > > >> >> > > > > > > > >
>>> > >> > > >> >> > > > > > > > > On 9/29/06, Artem Aliev
>>> > >> <ar...@gmail.com> wrote:
>>> > >> > > >> >> > > > > > > > > > Evgueni,
>>> > >> > > >> >> > > > > > > > > >
>>> > >> > > >> >> > > > > > > > > > I got most of your changes, but
>>> still
>>> > >> disagree
>>> > >> > > >> with all
>>> > >> > > >> >> > > > > > > > > > hythread/jthread interface changes.
>>> > >> Could leave
>>> > >> > > >> >> interface unchanged.
>>> > >> > > >> >> > > > > > > > > > See following possible
>>> solutions, that
>>> > >> could solve
>>> > >> > > >> >> the same problems
>>> > >> > > >> >> > > > > > > > > > without interface changes.
>>> > >> > > >> >> > > > > > > > > >
>>> > >> > > >> >> > > > > > > > > >
>>> > >> > > >> >> > > > > > > > > > 1) daemon attribute is a java
>>> > >> specific. (Andrey
>>> > >> > > >> >> mentioned this already).
>>> > >> > > >> >> > > > > > > > > > Could you please move it back. to
>>> > >> the jthread
>>> > >> > > >> >> layer. It is better
>>> > >> > > >> >> > > > > > > > > > to rename
>>> > >> > > >> >> > > > > > > > > >
>>> > >> hythread_wait_for_all_nondaemon_threads() to
>>> > >> > > >> >> > > > > > > > > >
>>> jthread_wait_for_all_nondaemon_threads().
>>> > >> > > >> >> > > > > > > > > Ok, I see no problems to move
>>> "daemon"
>>> > >> to java layer.
>>> > >> > > >> >> In that case:
>>> > >> > > >> >> > > > > > > > > 1) I will move
>>> > >> > > >> >> hythread_wait_for_all_nondaemon_threads() from
>>> > >> > > >> >> > > > > > > > > thread_init.c to one which implements
>>> > >> java layer.
>>> > >> > > >> >> > > > > > > > > 2) I will move daemon field from
>>> > >> HyThread structure.
>>> > >> > > >> >> > > > > > > > >
>>> > >> > > >> >> > > > > > > > > Agree?
>>> > >> > > >> >> > > > > > > >
>>> > >> > > >> >> > > > > > > > Sounds good to me.
>>> > >> > > >> >> > > > > > >
>>> > >> > > >> >> > > > > > > OK, will do that.
>>> > >> > > >> >> > > > > > >
>>> > >> > > >> >> > > > > > > >
>>> > >> > > >> >> > > > > > > >
>>> > >> > > >> >> > > > > > > > >
>>> > >> > > >> >> > > > > > > > > >
>>> > >> > > >> >> > > > > > > > > > 2) JavaVM could be retrieved from
>>> > >> JNIEnv by
>>> > >> > > >> >> jni_get_java_vm(). So
>>> > >> > > >> >> > > > > > > > > > let the jthread_create() and
>>> others to
>>> > >> use JNIEnv
>>> > >> > > >> >> (that is passed from
>>> > >> > > >> >> > > > > > > > > > java native method).
>>> > >> > > >> >> > > > > > > > > > The vm_attach could get old JNI env
>>> > >> and create new
>>> > >> > > >> >> one for the new thread.
>>> > >> > > >> >> > > > > > > > > > The first JNIEnv is created in
>>> > >> CreateVM call and
>>> > >> > > >> >> could be passed to
>>> > >> > > >> >> > > > > > > > > > the first thread at startup.
>>> > >> > > >> >> > > > > > > > > No, no, no. I completely disagree
>>> with
>>> > >> that!!! Why do
>>> > >> > > >> >> you like JNIEnv
>>> > >> > > >> >> > > > > > > > > but JavaVM. Why do you think that
>>> > >> passing JavaVM
>>> > >> > > >> >> instead of JNIEnv
>>> > >> > > >> >> > > > > > > > > makes TM less modular? I don't see
>>> any
>>> > >> difference
>>> > >> > > >> >> here.... It seems
>>> > >> > > >> >> > > > > > > > > for me like a big big hack to grab
>>> > >> JNIEnv from another
>>> > >> > > >> >> thread and pass
>>> > >> > > >> >> > > > > > > > > it to jthread_attach to perform
>>> > >> operations in the
>>> > >> > > >> >> current thread.
>>> > >> > > >> >> > > > > > > >
>>> > >> > > >> >> > > > > > > > TM needs to know JNIEnv, mainly for
>>> > >> managing the
>>> > >> > > >> >> references to
>>> > >> > > >> >> > > > > > > > objects, throwing exceptions and
>>> calling
>>> > >> run() method of
>>> > >> > > >> >> a new thread.
>>> > >> > > >> >> > > > > > > > JNI spec proposes that JNIEnv is valid
>>> > >> within the given
>>> > >> > > >> >> thread, this
>>> > >> > > >> >> > > > > > > > is why TM holds the JNIEnv pointer
>>> at the
>>> > >> moment. This
>>> > >> > > >> >> is why TM likes
>>> > >> > > >> >> > > > > > > > the JNIEnv.
>>> > >> > > >> >> > > > > > > >
>>> > >> > > >> >> > > > > > > > Having the JNIEnv, one is able to get
>>> > >> JavaVM but not
>>> > >> > > >> >> vise versa. This
>>> > >> > > >> >> > > > > > > > is why TM doesn't like the JavaVM :)
>>> > >> > > >> >> > > > > > > I see your point. Only one note this
>>> is true
>>> > >> for already
>>> > >> > > >> >> attached threads...
>>> > >> > > >> >> > > > > > >
>>> > >> > > >> >> > > > > > > >
>>> > >> > > >> >> > > > > > > > I agree with you that there is a design
>>> > >> flaw that the
>>> > >> > > >> >> JNIEnv is copied
>>> > >> > > >> >> > > > > > > > from the parent thread to a child
>>> thread
>>> > >> during thread
>>> > >> > > >> >> creation. I
>>> > >> > > >> >> > > > > > > > think it could be resolved via
>>> vm_attach()
>>> > >> hook - with
>>> > >> > > >> >> this event, VM
>>> > >> > > >> >> > > > > > > > might tell the TM what the JNIEnv
>>> pointer
>>> > >> for new thread
>>> > >> > > >> >> should be. I
>>> > >> > > >> >> > > > > > > > think you did that by extending the
>>> > >> vm_attach() call
>>> > >> > > >> >> with the JNIEnv**
>>> > >> > > >> >> > > > > > > > argument.
>>> > >> > > >> >> > > > > > > >
>>> > >> > > >> >> > > > > > > > What is not completely clear is, why do
>>> > >> you have to pass
>>> > >> > > >> >> the JavaVM
>>> > >> > > >> >> > > > > > > > forth and back, once from VM to TM, and
>>> > >> then back from
>>> > >> > > >> >> TM to VM again?
>>> > >> > > >> >> > > > > > > >
>>> > >> > > >> >> > > > > > > > If you need to know in jthread_attach,
>>> > >> which particular
>>> > >> > > >> >> VM vm_attach()
>>> > >> > > >> >> > > > > > > > event is coming from, you could have
>>> > >> vm_attach like
>>> > >> > > >> >> > > > > > > > vm_attach(JNIEnv* currentThreadEnv,
>>> JNIEnv**
>>> > >> > > >> >> newThreadEnv).
>>> > >> > > >> >> > > > > > > I'm a little bit confused.....Current
>>> thread
>>> > >> hasn't been
>>> > >> > > >> >> attached yet.
>>> > >> > > >> >> > > > > > > So there is no JNIEnv for it yet. How
>>> it can
>>> > >> be passed as
>>> > >> > > >> >> the first
>>> > >> > > >> >> > > > > > > parameter to vm_attach()?
>>> > >> > > >> >> > > > > > >
>>> > >> > > >> >> > > > > > > > Then you will be always able to get the
>>> > >> JavaVM from the
>>> > >> > > >> >> JNIEnv.
>>> > >> > > >> >> > > > > > > > The only difference is that you are
>>> > >> currently doing
>>> > >> > > >> >> JNIEnv->JavaVM
>>> > >> > > >> >> > > > > > > > conversion in the VMThreadManager,
>>> but why
>>> > >> can't you
>>> > >> > > >> >> just do this in
>>> > >> > > >> >> > > > > > > > vm_attach() without changing the
>>> interface
>>> > >> of the TM?
>>> > >> > > >> >> > > > > > > > So far JavaVM really looks like an
>>> extra
>>> > >> knowledge that
>>> > >> > > >> >> TM doesn't
>>> > >> > > >> >> > > > > > > > have to be aware of.
>>> > >> > > >> >> > > > > > > >
>>> > >> > > >> >> > > > > > > > > Moreover there is no JNIEnv when main
>>> > >> thread attaches
>>> > >> > > >> >> to VM. So we
>>> > >> > > >> >> > > > > > > > > should either keep it as is or change
>>> > >> original design
>>> > >> > > >> >> of TM and attach
>>> > >> > > >> >> > > > > > > > > thread to VM before attaching it
>>> to TM.
>>> > >> In that case
>>> > >> > > >> >> we will have
>>> > >> > > >> >> > > > > > > > > valid JNIEnv which can be passed to
>>> > >> jthread_atatch. We
>>> > >> > > >> >> need to think
>>> > >> > > >> >> > > > > > > > > over it twice before changing
>>> something....
>>> > >> > > >> >> > > > > > > >
>>> > >> > > >> >> > > > > > > > Right. For jthread_attach, JNIenv
>>> needs to
>>> > >> be changed
>>> > >> > > >> >> from being input
>>> > >> > > >> >> > > > > > > > parameter to being the output
>>> parameter.
>>> > >> The way how
>>> > >> > > >> >> JNIenv is
>>> > >> > > >> >> > > > > > > > obtained by TM should be vm_attach()
>>> event.
>>> > >> > > >> >> > > > > > > OK, JNIEnv is output parameter. And it
>>> > >> obtained by
>>> > >> > > >> >> vm_attach(). This
>>> > >> > > >> >> > > > > > > is exactly like I do in the patch. What I
>>> > >> don't understand
>>> > >> > > >> >> is how
>>> > >> > > >> >> > > > > > > jthread_attach knows to which VM the
>>> thread
>>> > >> should be
>>> > >> > > >> >> attached? Do you
>>> > >> > > >> >> > > > > > > suggest calling vm_attach first to create
>>> > >> JNIEnv it pass
>>> > >> > > >> >> it to
>>> > >> > > >> >> > > > > > > jthread_attach?
>>> > >> > > >> >> > > > > > >
>>> > >> > > >> >> > > > > > > >
>>> > >> > > >> >> > > > > > > > >
>>> > >> > > >> >> > > > > > > > >
>>> > >> > > >> >> > > > > > > > >
>>> > >> > > >> >> > > > > > > > > >
>>> > >> > > >> >> > > > > > > > > >
>>> > >> > > >> >> > > > > > > > > > 4) Original classlib hythread do
>>> not use
>>> > >> > > >> >> hythread_library_t in arguments,
>>> > >> > > >> >> > > > > > > > > > It uses following code:
>>> > >> > > >> >> > > > > > > > > >
>>> > >> > > >> >> > > > > > > > > > hythread_library_t lib =
>>> GLOBAL_DATA
>>> > >> > > >> >> (default_library);
>>> > >> > > >> >> > > > > > > > > > or
>>> > >> > > >> >> > > > > > > > > > hythread_library_t library =
>>> thread-
>>> > >> >library;
>>> > >> > > >> >> > > > > > > > > >
>>> > >> > > >> >> > > > > > > > > > So could you please use the same
>>> > >> mechanism and
>>> > >> > > >> >> remove hythread_*_ex >functions.
>>> > >> > > >> >> > > > > > > > > Let's see if classlib's hythread
>>> needs
>>> > >> changing first.
>>> > >> > > >> >> It seems for me
>>> > >> > > >> >> > > > > > > > > such code prevents us from having
>>> multi VM.
>>> > >> > > >> >> > > > > > > > >
>>> > >> > > >> >> > > > > > > > > >
>>> > >> > > >> >> > > > > > > > > > 5. You introduce more then one jni
>>> > >> env, but still
>>> > >> > > >> >> use global variable for it.
>>> > >> > > >> >> > > > > > > > > > So all changes like following:
>>> > >> > > >> >> > > > > > > > > > - JNIEnv *jenv = (JNIEnv*)
>>> > >> jni_native_intf;
>>> > >> > > >> >> > > > > > > > > > + JNIEnv *jenv =
>>> jni_native_intf;
>>> > >> > > >> >> > > > > > > > > >
>>> > >> > > >> >> > > > > > > > > > should be like:
>>> > >> > > >> >> > > > > > > > > > - JNIEnv *jenv = (JNIEnv*)
>>> > >> jni_native_intf;
>>> > >> > > >> >> > > > > > > > > > + JNIEnv *jenv = get_jni_env
>>> > >> (jthread_self());
>>> > >> > > >> >> > > > > > > > >
>>> > >> > > >> >> > > > > > > > > Ok, I see. I agree that global
>>> > >> jni_native_intf should
>>> > >> > > >> >> not be used.
>>> > >> > > >> >> > > > > > > > > There was simple reason why I altered
>>> > >> such lines.
>>> > >> > > >> >> Because I changed
>>> > >> > > >> >> > > > > > > > > the type of jni_native_intf and no
>>> > >> casting operator
>>> > >> > > >> >> is needed now. To
>>> > >> > > >> >> > > > > > > > > be honest I think get_jni_env
>>> > >> (jthread_self()) can be
>>> > >> > > >> >> good as temporary
>>> > >> > > >> >> > > > > > > > > solution only. Lets wait for
>>> design of
>>> > >> multi VM and
>>> > >> > > >> >> fix it according
>>> > >> > > >> >> > > > > > > > > to it.
>>> > >> > > >> >> > > > > > > >
>>> > >> > > >> >> > > > > > > > While we are in JNI code, we always
>>> have
>>> > >> the JNIenv (at
>>> > >> > > >> >> least
>>> > >> > > >> >> > > > > > > > initially it comes from Java code).
>>> If we
>>> > >> consider VM
>>> > >> > > >> >> code as if it
>>> > >> > > >> >> > > > > > > > was a JNI application, then it seems
>>> like
>>> > >> we should be
>>> > >> > > >> >> just passing
>>> > >> > > >> >> > > > > > > > JNIEnv as a parameter to all
>>> functions in
>>> > >> VM. Or, we can
>>> > >> > > >> >> be taking it
>>> > >> > > >> >> > > > > > > > from TLS (via jthread_self()),
>>> depending
>>> > >> on which way is
>>> > >> > > >> >> faster...
>>> > >> > > >> >> > > > > > > Agree.
>>> > >> > > >> >> > > > > > >
>>> > >> > > >> >> > > > > > > >
>>> > >> > > >> >> > > > > > > > >
>>> > >> > > >> >> > > > > > > > > >
>>> > >> > > >> >> > > > > > > > > > 6). And small remarks:
>>> > >> > > >> >> > > > > > > > > > +jint vm_init1(JavaVM_Internal *
>>> java_vm,
>>> > >> > > >> >> JavaVMInitArgs * vm_arguments);
>>> > >> > > >> >> > > > > > > > > > +jint vm_init2(JNIEnv_Internal *
>>> > >> jni_env);
>>> > >> > > >> >> > > > > > > > > > Could you make names more
>>> meaningful,
>>> > >> then 1,2,3...?
>>> > >> > > >> >> > > > > > > > > Ok, will do that.
>>> > >> > > >> >> > > > > > > > >
>>> > >> > > >> >> > > > > > > > > >
>>> > >> > > >> >> > > > > > > > > > class VM_thread {
>>> > >> > > >> >> > > > > > > > > > ...
>>> > >> > > >> >> > > > > > > > > > + JNIEnv_Internal * jni_env;
>>> > >> > > >> >> > > > > > > > > > The jthread already has the jni_env
>>> > >> pointer, you do
>>> > >> > > >> >> not need to
>>> > >> > > >> >> > > > > > > > > > duplicate it here.
>>> > >> > > >> >> > > > > > > > > > forexample by using
>>> > >> > > >> >> jthread_get_JNI_env(jthread_self());
>>> > >> > > >> >> > > > > > > > >
>>> > >> > > >> >> > > > > > > > > Yes I know. I don't see any problems
>>> > >> here. Some times
>>> > >> > > >> >> it is much more
>>> > >> > > >> >> > > > > > > > > convenient to get JNIEnv from
>>> VM_thread
>>> > >> structure (and
>>> > >> > > >> >> faster) instead
>>> > >> > > >> >> > > > > > > > > of doing jthread_get_JNI_env
>>> (jthread_self
>>> > >> ()). So I
>>> > >> > > >> >> need strong
>>> > >> > > >> >> > > > > > > > > arguments for removing it. Again it
>>> > >> seems that should
>>> > >> > > >> >> be addressed in
>>> > >> > > >> >> > > > > > > > > design of multi VM. So lets forget
>>> about
>>> > >> it for a
>>> > >> > > >> >> while...
>>> > >> > > >> >> > > > > > > >
>>> > >> > > >> >> > > > > > > > I think that the data duplication would
>>> > >> always serve as
>>> > >> > > >> >> a potential
>>> > >> > > >> >> > > > > > > > source of errors - while updating
>>> one copy
>>> > >> of object,
>>> > >> > > >> >> you may forget
>>> > >> > > >> >> > > > > > > > to update the other, often resulting
>>> into
>>> > >> a strange
>>> > >> > > >> >> behavior of the
>>> > >> > > >> >> > > > > > > > whole application. Let's see what
>>> are the
>>> > >> specific
>>> > >> > > >> >> performance
>>> > >> > > >> >> > > > > > > > concerns that have to be addressed.
>>> To get
>>> > >> VM_thread
>>> > >> > > >> >> structure, you
>>> > >> > > >> >> > > > > > > > would eventually go to the TLS, just
>>> like
>>> > >> > > >> >> > > > > > > > jthread_get_JNI_env(jthread_self()
>>> would do.
>>> > >> > > >> >> > > > > > > If there is already VM_thread
>>> structure for
>>> > >> some reasons
>>> > >> > > >> >> then there
>>> > >> > > >> >> > > > > > > will be no extra access to TLS. It is
>>> > >> definitely much
>>> > >> > > >> more in
>>> > >> > > >> >> > > > > > > jthread_get_JNI_env(jthread_self()
>>> than just
>>> > >> one TLS
>>> > >> > > >> >> access and one
>>> > >> > > >> >> > > > > > > dereferncing. I don't think it is a
>>> really
>>> > >> big problem
>>> > >> > > >> >> now. Do you
>>> > >> > > >> >> > > > > > > agree to look at this later. I guess
>>> multi VM
>>> > >> > > >> >> implementation will
>>> > >> > > >> >> > > > > > > alter it in any case.
>>> > >> > > >> >> > > > > > >
>>> > >> > > >> >> > > > > > > Thanks
>>> > >> > > >> >> > > > > > > Evgueni
>>> > >> > > >> >> > > > > > >
>>> > >> > > >> >> > > > > > > >
>>> > >> > > >> >> > > > > > > > Thanks,
>>> > >> > > >> >> > > > > > > > Andrey.
>>> > >> > > >> >> > > > > > > >
>>> > >> > > >> >> > > > > > > > >
>>> > >> > > >> >> > > > > > > > > Evgueni
>>> > >> > > >> >> > > > > > > > > >
>>> > >> > > >> >> > > > > > > > > > Thanks
>>> > >> > > >> >> > > > > > > > > > Artem
>>> > >> > > >> >> > > > > > > > > >
>>> > >> > > >> >> > > > > > > > > > On 9/28/06, Evgueni Brevnov
>>> > >> > > >> >> <ev...@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.
>>> > >> > > >> >> > > > > > > > > > >
>>> > >> > > >> >> > > > > > > > > > > Thanks
>>> > >> > > >> >> > > > > > > > > > > Evgueni
>>> > >> > > >> >> > > > > > > > > > >
>>> > >> > > >> >> > > > > > > > > > > On 9/28/06, Geir Magnusson Jr.
>>> > >> <ge...@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
>>> > >> > > >> >> <we...@gmail.com> wrote:
>>> > >> > > >> >> > > > > > > > > > > > >> On 9/26/06, Evgueni Brevnov
>>> > >> > > >> >> <ev...@gmail.com> wrote:
>>> > >> > > >> >> > > > > > > > > > > > >> >
>>> > >> > > >> >> > > > > > > > > > > > >> > On 9/27/06, Andrey
>>> Chernyshev
>>> > >> > > >> >> <a....@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
>>> > >> > > >> >> > > > > > > > > > >
>>> > >> > > >> >> > > > > > > > > > >
>>> > >> > > >> >> > > > > > > > > >
>>> > >> > > >> >> > > > > > > > > >
>>> > >> > > >> >>
>>> > >>
>>> --------------------------------------------------------------------
>>> -
>>> > >> > > >> >> > > > > > > > > > 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
>>> > >> > > >> >> > > > > > > > >
>>> > >> > > >> >> > > > > > > > >
>>> > >> > > >> >> > > > > > > >
>>> > >> > > >> >> > > > > > > >
>>> > >> > > >> >> > > > > > > > --
>>> > >> > > >> >> > > > > > > > Andrey Chernyshev
>>> > >> > > >> >> > > > > > > > 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
>>> > >> > > >> >> > > > > >
>>> > >> > > >> >> > > > > >
>>> > >> > > >> >> > > > >
>>> > >> > > >> >> > > > >
>>> > >> > > >> >> > > > > --
>>> > >> > > >> >> > > > > Andrey Chernyshev
>>> > >> > > >> >> > > > > 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
>>> > >> > > >> >> > > >
>>> > >> > > >> >> > > >
>>> > >> > > >> >> > >
>>> > >> > > >> >> > >
>>> > >> > > >> >> > > --
>>> > >> > > >> >> > > Andrey Chernyshev
>>> > >> > > >> >> > > 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
>>> > >> > > >>
>>> > >> > > >>
>>> > >> > > >
>>> > >> > > >
>>> > >>
>>> --------------------------------------------------------------------
>>> -
>>> > >> > > > 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
>>> > >
>>> >
>>> >
>>> >
>>> --------------------------------------------------------------------
>>> -
>>> > 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
>
---------------------------------------------------------------------
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
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
sure - I'll redo the whole thing from clean...
On Oct 9, 2006, at 9:45 AM, Evgueni Brevnov wrote:
> BTW, could you verify the right patch for tests was used? It should be
> tests.final.2.patch...... Sorry for the mess with patches....
>
> Evgueni
>
> On 10/9/06, Evgueni Brevnov <ev...@gmail.com> wrote:
>> I put debug printing into test_ti_instrum.c and attached it to JIRA.
>> Could you run it on your machine and send me console output.
>>
>> Evgueni
>>
>> On 10/9/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>> > I keep getting a failure when running the tests -
>> >
>> > test_jthread_get_all-threads failling the assertion at
>> > test_ti_instrum.c:80
>> >
>> > geir
>> >
>> > On Oct 8, 2006, at 7:19 AM, Evgueni Brevnov wrote:
>> >
>> > > While running cunit on Linux it turned out one test case fails
>> some
>> > > time. The fix is in tests.final.2.patch.
>> > >
>> > > So the last versions to be committed:
>> > > invocation_api.final.patch
>> > > build.final.2.patch
>> > > tests.final.2.patch
>> > >
>> > > Evgueni
>> > >
>> > >
>> > > On 10/8/06, Evgueni Brevnov <ev...@gmail.com> wrote:
>> > >> I mahaged to resolve the problem on Linux.... will update
>> > >> build.final.patch with build.final.2.patch in a while
>> > >>
>> > >> On 10/8/06, Evgueni Brevnov <ev...@gmail.com> wrote:
>> > >> > Hi,
>> > >> >
>> > >> > Oh! Ooh! I did that..... I passed cunit, somke, kernel
>> tests on
>> > >> > Windows and smoke, kernel tests on Linux. Unfortunately I
>> failed to
>> > >> > link cunit tests on Linux so far. So I disabled cunit on Linux
>> > >> until
>> > >> > the problem is solved. I believe it is acceptable as short
>> term
>> > >> > solution. I found several problems in cunit tests. I will come
>> > >> up with
>> > >> > my findings later (not today).
>> > >> >
>> > >> > Use latest patches from HARMONY-1582. They are marked as
>> final.
>> > >> There
>> > >> > are three patches. One for build module, one for cunit
>> tests and
>> > >> one
>> > >> > for VM itself.
>> > >> >
>> > >> > Thanks
>> > >> > Evgueni
>> > >> >
>> > >> >
>> > >> > On 10/6/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>> > >> > > Nooooooo! LOL
>> > >> > >
>> > >> > > I'm here waiting - This will unblock a whole bunch of
>> things :)
>> > >> > >
>> > >> > > Thanks for the effort
>> > >> > >
>> > >> > > Evgueni Brevnov wrote:
>> > >> > > > Geir,
>> > >> > > >
>> > >> > > > That's terrible. We have power outage....servers are
>> down. I
>> > >> can't
>> > >> > > > send the patches now.... will do it tomorrow
>> > >> > > >
>> > >> > > > Evgueni
>> > >> > > > On 10/5/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>> > >> > > >> woo hoo! here we go...
>> > >> > > >>
>> > >> > > >>
>> > >> > > >> Andrey Chernyshev wrote:
>> > >> > > >> > Hi Evgueni,
>> > >> > > >> >
>> > >> > > >> > On 10/4/06, Evgueni Brevnov <ev...@gmail.com>
>> > >> wrote:
>> > >> > > >> >> Hi All,
>> > >> > > >> >>
>> > >> > > >> >> I have attached updated patch to the JIRA. It should
>> > >> resolve remain
>> > >> > > >> >> concerns. Andrey, could you give a green light now?
>> > >> > > >> >
>> > >> > > >> > Thanks for updating the patch! I agree it it can be
>> > >> committed, at
>> > >> > > >> > least signatures look good. 5 revisions seem like more
>> > >> than enough :).
>> > >> > > >> > Anyways, I think the remaining issues can be resolved
>> > >> with additional
>> > >> > > >> > patches. Thanks again for the good work and your
>> patience.
>> > >> > > >> >
>> > >> > > >> > Thanks,
>> > >> > > >> > Andrey.
>> > >> > > >> >
>> > >> > > >> >>
>> > >> > > >> >> Thanks
>> > >> > > >> >> Evgueni
>> > >> > > >> >>
>> > >> > > >> >> On 10/4/06, Evgueni Brevnov
>> <ev...@gmail.com>
>> > >> wrote:
>> > >> > > >> >> > Andrey,
>> > >> > > >> >> >
>> > >> > > >> >> > I see your points. I think both approaches have
>> > >> advantages and
>> > >> > > >> >> > disadvantages. I think it is quite hard to say which
>> > >> approach is
>> > >> > > >> >> > better until we play with one VM only. I still feel
>> > >> like introducing
>> > >> > > >> >> > one more dependence is better than spreading code
>> > >> which deals with
>> > >> > > >> >> > attachment among VM and TM. We really get stuck. OK,
>> > >> just because I
>> > >> > > >> >> > want to move forward I will do required changes
>> to remove
>> > >> > > >> >> > vm_create_jthread from TM. I believe that will
>> resolve
>> > >> all our
>> > >> > > >> >> > disagreements and the patch will be applied soon.
>> > >> > > >> >> >
>> > >> > > >> >> >
>> > >> > > >> >> > Thanks
>> > >> > > >> >> > Evgueni.
>> > >> > > >> >> >
>> > >> > > >> >> > On 10/4/06, Andrey Chernyshev
>> > >> <a....@gmail.com> wrote:
>> > >> > > >> >> > > On 10/3/06, Evgueni Brevnov
>> > >> <ev...@gmail.com> wrote:
>> > >> > > >> >> > > > On 10/3/06, Andrey Chernyshev
>> > >> <a....@gmail.com> wrote:
>> > >> > > >> >> > > > > On 10/2/06, Evgueni Brevnov
>> > >> <ev...@gmail.com> wrote:
>> > >> > > >> >> > > > > > Andrey,
>> > >> > > >> >> > > > > >
>> > >> > > >> >> > > > > > Just to be clear.... I agree with you it
>> is more
>> > >> > > >> convenient if
>> > >> > > >> >> > > > > > jthread_create takes JNIEnv instead of
>> JavaVM. It
>> > >> > > >> reflects that
>> > >> > > >> >> > > > > > current thread has been attached already. Do
>> > >> you think it
>> > >> > > >> >> makes sense
>> > >> > > >> >> > > > > > to get rid of JNIEnv and use
>> > >> jthread_get_JNI_env in that
>> > >> > > >> case?
>> > >> > > >> >> > > > >
>> > >> > > >> >> > > > > The jthread_* layer is designed like if it
>> were
>> > >> a regular JNI
>> > >> > > >> >> > > > > application which is meant to be called
>> from the
>> > >> Java code,
>> > >> > > >> hence
>> > >> > > >> >> > > > > every function on that layer receives
>> JNIenv. We
>> > >> can probably
>> > >> > > >> >> get rid
>> > >> > > >> >> > > > > of the JNEnv parameter for jthread_*
>> functions,
>> > >> assuming that
>> > >> > > >> >> TM can
>> > >> > > >> >> > > > > always extract JNIenv for the current
>> thread with
>> > >> > > >> >> > > > > jthread_get_JNI_env().
>> > >> > > >> >> > > > > My only concern would be the performance -
>> once
>> > >> the JNIenv is
>> > >> > > >> >> already
>> > >> > > >> >> > > > > known for the native part of the kernel
>> classes
>> > >> impl, it
>> > >> > > >> must be
>> > >> > > >> >> > > > > cheaper to pass JNIEnv to TM as an extra
>> > >> parameter rather than
>> > >> > > >> >> extract
>> > >> > > >> >> > > > > it from the TLS again.
>> > >> > > >> >> > > > > Other than that, I see no strong advantages in
>> > >> keeping JNIEnv
>> > >> > > >> >> parameter.
>> > >> > > >> >> > > > >
>> > >> > > >> >> > > > >
>> > >> > > >> >> > > > > > Regarding jthread_attach. I still didn't get
>> > >> your point....
>> > >> > > >> >> Clarify it
>> > >> > > >> >> > > > > > please if you think jhread_attach should be
>> > >> modified.
>> > >> > > >> >> > > > >
>> > >> > > >> >> > > > > Sorry for being not clear: I think for
>> > >> jthread_attach, we have
>> > >> > > >> >> two options:
>> > >> > > >> >> > > > > 1) Make JNIEnv input parameter - it must be
>> new
>> > >> JNIEnv that VM
>> > >> > > >> >> > > > > pre-allocates for the new Java thread.
>> > >> jthread_attach
>> > >> > > >> would just
>> > >> > > >> >> > > > > associate it with the current thread.
>> > >> > > >> >> > > > >
>> > >> > > >> >> > > > > 2) Obtain JNIEnv via vm_attach() callback. In
>> > >> this case, if
>> > >> > > >> >> > > > > vm_attach() callback implementation needs to
>> > >> know for which
>> > >> > > >> >> JavaVM new
>> > >> > > >> >> > > > > JNIenv has to be allocated, then we'll need to
>> > >> add JavaVM as
>> > >> > > >> >> input
>> > >> > > >> >> > > > > parameter for jthread_attach().
>> > >> > > >> >> > > > > I think both options should be fine, (1) would
>> > >> probably
>> > >> > > >> keep TM
>> > >> > > >> >> > > > > interface a bit lighter, though (2) may look
>> > >> more closer to
>> > >> > > >> >> the JNI
>> > >> > > >> >> > > > > invocation API idea.
>> > >> > > >> >> > > > > So I think adding JavaVM specifically for
>> > >> jthread_attach
>> > >> > > >> may make
>> > >> > > >> >> > > > > sense given the explanation you provided
>> earlier.
>> > >> > > >> >> > > > >
>> > >> > > >> >> > > > > The concern I would have regarding the
>> proposed
>> > >> jthread_attach
>> > >> > > >> >> > > > > implementation is a call to
>> vm_create_jthread()
>> > >> - this call
>> > >> > > >> >> introduces
>> > >> > > >> >> > > > > an extra dependency of TM on vmcore that I'd
>> > >> prefer to be
>> > >> > > >> >> avoided. In
>> > >> > > >> >> > > > > the original version, jthread_attach() was
>> > >> taking jthread
>> > >> > > >> >> argument of
>> > >> > > >> >> > > > > the already prepared j.l.Thread.
>> > >> > > >> >> > > >
>> > >> > > >> >> > > > I understand your concern. Unfortunately I don't
>> > >> see what we
>> > >> > > >> can do
>> > >> > > >> >> > > > here. Let me explain. In the beginning you
>> have an
>> > >> unattached
>> > >> > > >> >> native
>> > >> > > >> >> > > > thread. To be able to call java code (which is
>> > >> required for
>> > >> > > >> >> > > > constructing j.l.Thread instance) the thread
>> > >> should be attached
>> > >> > > >> >> first.
>> > >> > > >> >> > > > To be specific it should be attached to VM by
>> > >> calling vm_attach
>> > >> > > >> >> which
>> > >> > > >> >> > > > will return a valid JNIEnv It is valid to use
>> JNI
>> > >> from that
>> > >> > > >> moment.
>> > >> > > >> >> > > > Obtained JNIEnv can be used to execute java code
>> > >> and create
>> > >> > > >> >> j.l.Thread
>> > >> > > >> >> > > > instance. Since we do vm_attach in
>> jthread_attach
>> > >> we need to do
>> > >> > > >> >> > > > vm_create_jthread inside jthread_atach as well.
>> > >> > > >> >> > > > Of course it can be an alternative to do
>> vm_attach
>> > >> and
>> > >> > > >> >> > > > vm_create_jthread outside of TM right before
>> > >> jthread_attach.
>> > >> > > >> >> Sure it
>> > >> > > >> >> > > > will reduce one dependence between VM and TM.
>> But
>> > >> it seems like
>> > >> > > >> >> > > > artificial action for me just because of
>> > >> dependency....
>> > >> > > >> >> > >
>> > >> > > >> >> > > Why do you think it is artificial? I would rather
>> > >> prefer not to
>> > >> > > >> throw
>> > >> > > >> >> > > vm_attach event from the jthread_attach() call at
>> > >> all than to add
>> > >> > > >> >> > > extra dependency. The idea of jthread layer is a
>> > >> Java face to
>> > >> > > >> >> > > hythread, it is meant to know either a little or
>> > >> nothing about the
>> > >> > > >> >> > > rest of VM. It may be logical to throw vm_attach
>> > >> call from the
>> > >> > > >> newly
>> > >> > > >> >> > > created thread, because there is no other way
>> to let
>> > >> know VM
>> > >> > > >> the new
>> > >> > > >> >> > > thread is created. VM attach is a different case -
>> > >> VM already
>> > >> > > >> knows
>> > >> > > >> >> > > about new Java thread at the time of the
>> > >> AttachCurrentThread call.
>> > >> > > >> >> > >
>> > >> > > >> >> > > >
>> > >> > > >> >> > > > > Do you think it makes sense to replace a
>> single
>> > >> jthread
>> > >> > > >> >> parameter with
>> > >> > > >> >> > > > > a variety of stuff (like thread group,
>> name)? It
>> > >> seems the
>> > >> > > >> only
>> > >> > > >> >> > > > > purpose of at these args is to be passed
>> back to
>> > >> VM for
>> > >> > > >> >> > > > > vm_jthread_create(). I would suggest to change
>> > >> this and try
>> > >> > > >> doing
>> > >> > > >> >> > > > > either of:
>> > >> > > >> >> > > > > 1) Make signature of jthread_attach with 3
>> args,
>> > >> JavaVM,
>> > >> > > >> >> jthread and the daemon.
>> > >> > > >> >> > > > Why do you want to pass daemon to TM but
>> thread's
>> > >> name and
>> > >> > > >> >> group. Just
>> > >> > > >> >> > > > because current TM doesn't need such
>> information?
>> > >> What if it is
>> > >> > > >> >> > > > required to get thread name later? Say by
>> introducing
>> > >> > > >> >> > >
>> > >> > > >> >> > > I imagine you need a daemon attribute since the TM
>> > >> is still
>> > >> > > >> managing
>> > >> > > >> >> > > the thread daemonality. TM is not managing thread
>> > >> name and group -
>> > >> > > >> >> > > they are all kept on the Java level, hence passing
>> > >> them may be
>> > >> > > >> >> > > excessive.
>> > >> > > >> >> > >
>> > >> > > >> >> > > > jthread_get_name... What will you do in that
>> case?
>> > >> Let me
>> > >> > > >> guess you
>> > >> > > >> >> > > > will call j.l.Thread.getName. Right. Ok! In that
>> > >> case I see no
>> > >> > > >> >> > > > problems to call j.l.Thread.isDaemon. Do you
>> > >> agree? So it
>> > >> > > >> doesn't
>> > >> > > >> >> > >
>> > >> > > >> >> > > As I suggested earlier, the best way to handle
>> > >> daemonality would
>> > >> > > >> >> > > probably be in pure Java - in j.l.Thread (or
>> > >> > > >> j.l.VMThreadManager) or
>> > >> > > >> >> > > whatever. You already lifted it up to the jthread
>> > >> level, but
>> > >> > > >> what if
>> > >> > > >> >> > > we can go a little bit higher...
>> > >> > > >> >> > >
>> > >> > > >> >> > > > seems to be a good design to pass only part
>> of the
>> > >> > > >> information to
>> > >> > > >> >> > > > jthread_atach. Lets look at the signature of
>> > >> > > >> >> AttachCurrentThread. It
>> > >> > > >> >> > > > takes exactly these three parameters (daemon,
>> > >> name, group)
>> > >> > > >> >> passed as a
>> > >> > > >> >> > > > structure. I was thinking about having
>> exactly the
>> > >> same
>> > >> > > >> >> structure as
>> > >> > > >> >> > > > third parameter of jthread_attach but it occured
>> > >> to be more
>> > >> > > >> >> convinient
>> > >> > > >> >> > > > to pass them seperatly. Although I don't see
>> > >> strong reasons
>> > >> > > >> against
>> > >> > > >> >> > > > having a structure a third parameter.
>> > >> > > >> >> > >
>> > >> > > >> >> > > I see. Acually, I would love to keep the
>> > >> jthread_attach func-ty at
>> > >> > > >> >> the
>> > >> > > >> >> > > minimum level which will be needed to handle the
>> > >> only data that TM
>> > >> > > >> >> > > should be aware of. We need a formal boundary
>> > >> between jthread
>> > >> > > >> layer
>> > >> > > >> >> > > and vmcore (otherwise jthread won't have a much of
>> > >> sense, one may
>> > >> > > >> >> > > consider it just as a convenience set of functions
>> > >> in vmcore which
>> > >> > > >> >> are
>> > >> > > >> >> > > doing something with threading).
>> > >> > > >> >> > >
>> > >> > > >> >> > > >
>> > >> > > >> >> > > > > 2) Move the implementation of
>> vm_create_jtrhead
>> > >> () to
>> > >> > > >> >> > > > > thread_java_basic.c - could it be written in
>> > >> pure JNI without
>> > >> > > >> >> using
>> > >> > > >> >> > > > > internal VM API like class_alloc_new_object()?
>> > >> > > >> >> > > >
>> > >> > > >> >> > > > Yes, this can be done but it doesn't fix the
>> > >> problem. You still
>> > >> > > >> >> need
>> > >> > > >> >> > > > to know about internal constructor of j.l.Thread
>> > >> > > >> >> > >
>> > >> > > >> >> > > That's bad. Given what you said, now it seems that
>> > >> the most
>> > >> > > >> >> preferable
>> > >> > > >> >> > > sequence for AttachCurrentThread impl still
>> would be
>> > >> like:
>> > >> > > >> >> > > JNIEnv = vm_attach();
>> > >> > > >> >> > > jthread = create_jthread(JNIenv)
>> > >> > > >> >> > > jthread_attach(JNIEnv, jthread) // stores
>> JNIEnv and
>> > >> Hythread into
>> > >> > > >> >> > > TLS, doesn't call vm_attach any longer.
>> > >> > > >> >> > > - this is almost what we had from the beginning...
>> > >> > > >> >> > >
>> > >> > > >> >> > > Thanks,
>> > >> > > >> >> > > Andrey.
>> > >> > > >> >> > >
>> > >> > > >> >> > > >
>> > >> > > >> >> > > >
>> > >> > > >> >> > > > Thanks
>> > >> > > >> >> > > > Evgueni
>> > >> > > >> >> > > > >
>> > >> > > >> >> > > > >
>> > >> > > >> >> > > > > Thanks,
>> > >> > > >> >> > > > > Andrey.
>> > >> > > >> >> > > > >
>> > >> > > >> >> > > > > >
>> > >> > > >> >> > > > > > Thank you
>> > >> > > >> >> > > > > > Evgueni
>> > >> > > >> >> > > > > >
>> > >> > > >> >> > > > > > On 10/2/06, Evgueni Brevnov
>> > >> <ev...@gmail.com>
>> > >> > > >> wrote:
>> > >> > > >> >> > > > > > > On 9/29/06, Andrey Chernyshev
>> > >> <a....@gmail.com>
>> > >> > > >> >> wrote:
>> > >> > > >> >> > > > > > > > On 9/29/06, Evgueni Brevnov
>> > >> <ev...@gmail.com>
>> > >> > > >> >> wrote:
>> > >> > > >> >> > > > > > > > > Artem,
>> > >> > > >> >> > > > > > > > >
>> > >> > > >> >> > > > > > > > > Thank you for your feedback....
>> find my
>> > >> inlined.....
>> > >> > > >> >> > > > > > > > >
>> > >> > > >> >> > > > > > > > > On 9/29/06, Artem Aliev
>> > >> <ar...@gmail.com> wrote:
>> > >> > > >> >> > > > > > > > > > Evgueni,
>> > >> > > >> >> > > > > > > > > >
>> > >> > > >> >> > > > > > > > > > I got most of your changes, but
>> still
>> > >> disagree
>> > >> > > >> with all
>> > >> > > >> >> > > > > > > > > > hythread/jthread interface changes.
>> > >> Could leave
>> > >> > > >> >> interface unchanged.
>> > >> > > >> >> > > > > > > > > > See following possible solutions,
>> that
>> > >> could solve
>> > >> > > >> >> the same problems
>> > >> > > >> >> > > > > > > > > > without interface changes.
>> > >> > > >> >> > > > > > > > > >
>> > >> > > >> >> > > > > > > > > >
>> > >> > > >> >> > > > > > > > > > 1) daemon attribute is a java
>> > >> specific. (Andrey
>> > >> > > >> >> mentioned this already).
>> > >> > > >> >> > > > > > > > > > Could you please move it back. to
>> > >> the jthread
>> > >> > > >> >> layer. It is better
>> > >> > > >> >> > > > > > > > > > to rename
>> > >> > > >> >> > > > > > > > > >
>> > >> hythread_wait_for_all_nondaemon_threads() to
>> > >> > > >> >> > > > > > > > > >
>> jthread_wait_for_all_nondaemon_threads().
>> > >> > > >> >> > > > > > > > > Ok, I see no problems to move "daemon"
>> > >> to java layer.
>> > >> > > >> >> In that case:
>> > >> > > >> >> > > > > > > > > 1) I will move
>> > >> > > >> >> hythread_wait_for_all_nondaemon_threads() from
>> > >> > > >> >> > > > > > > > > thread_init.c to one which implements
>> > >> java layer.
>> > >> > > >> >> > > > > > > > > 2) I will move daemon field from
>> > >> HyThread structure.
>> > >> > > >> >> > > > > > > > >
>> > >> > > >> >> > > > > > > > > Agree?
>> > >> > > >> >> > > > > > > >
>> > >> > > >> >> > > > > > > > Sounds good to me.
>> > >> > > >> >> > > > > > >
>> > >> > > >> >> > > > > > > OK, will do that.
>> > >> > > >> >> > > > > > >
>> > >> > > >> >> > > > > > > >
>> > >> > > >> >> > > > > > > >
>> > >> > > >> >> > > > > > > > >
>> > >> > > >> >> > > > > > > > > >
>> > >> > > >> >> > > > > > > > > > 2) JavaVM could be retrieved from
>> > >> JNIEnv by
>> > >> > > >> >> jni_get_java_vm(). So
>> > >> > > >> >> > > > > > > > > > let the jthread_create() and
>> others to
>> > >> use JNIEnv
>> > >> > > >> >> (that is passed from
>> > >> > > >> >> > > > > > > > > > java native method).
>> > >> > > >> >> > > > > > > > > > The vm_attach could get old JNI env
>> > >> and create new
>> > >> > > >> >> one for the new thread.
>> > >> > > >> >> > > > > > > > > > The first JNIEnv is created in
>> > >> CreateVM call and
>> > >> > > >> >> could be passed to
>> > >> > > >> >> > > > > > > > > > the first thread at startup.
>> > >> > > >> >> > > > > > > > > No, no, no. I completely disagree with
>> > >> that!!! Why do
>> > >> > > >> >> you like JNIEnv
>> > >> > > >> >> > > > > > > > > but JavaVM. Why do you think that
>> > >> passing JavaVM
>> > >> > > >> >> instead of JNIEnv
>> > >> > > >> >> > > > > > > > > makes TM less modular? I don't see any
>> > >> difference
>> > >> > > >> >> here.... It seems
>> > >> > > >> >> > > > > > > > > for me like a big big hack to grab
>> > >> JNIEnv from another
>> > >> > > >> >> thread and pass
>> > >> > > >> >> > > > > > > > > it to jthread_attach to perform
>> > >> operations in the
>> > >> > > >> >> current thread.
>> > >> > > >> >> > > > > > > >
>> > >> > > >> >> > > > > > > > TM needs to know JNIEnv, mainly for
>> > >> managing the
>> > >> > > >> >> references to
>> > >> > > >> >> > > > > > > > objects, throwing exceptions and calling
>> > >> run() method of
>> > >> > > >> >> a new thread.
>> > >> > > >> >> > > > > > > > JNI spec proposes that JNIEnv is valid
>> > >> within the given
>> > >> > > >> >> thread, this
>> > >> > > >> >> > > > > > > > is why TM holds the JNIEnv pointer at
>> the
>> > >> moment. This
>> > >> > > >> >> is why TM likes
>> > >> > > >> >> > > > > > > > the JNIEnv.
>> > >> > > >> >> > > > > > > >
>> > >> > > >> >> > > > > > > > Having the JNIEnv, one is able to get
>> > >> JavaVM but not
>> > >> > > >> >> vise versa. This
>> > >> > > >> >> > > > > > > > is why TM doesn't like the JavaVM :)
>> > >> > > >> >> > > > > > > I see your point. Only one note this is
>> true
>> > >> for already
>> > >> > > >> >> attached threads...
>> > >> > > >> >> > > > > > >
>> > >> > > >> >> > > > > > > >
>> > >> > > >> >> > > > > > > > I agree with you that there is a design
>> > >> flaw that the
>> > >> > > >> >> JNIEnv is copied
>> > >> > > >> >> > > > > > > > from the parent thread to a child thread
>> > >> during thread
>> > >> > > >> >> creation. I
>> > >> > > >> >> > > > > > > > think it could be resolved via
>> vm_attach()
>> > >> hook - with
>> > >> > > >> >> this event, VM
>> > >> > > >> >> > > > > > > > might tell the TM what the JNIEnv
>> pointer
>> > >> for new thread
>> > >> > > >> >> should be. I
>> > >> > > >> >> > > > > > > > think you did that by extending the
>> > >> vm_attach() call
>> > >> > > >> >> with the JNIEnv**
>> > >> > > >> >> > > > > > > > argument.
>> > >> > > >> >> > > > > > > >
>> > >> > > >> >> > > > > > > > What is not completely clear is, why do
>> > >> you have to pass
>> > >> > > >> >> the JavaVM
>> > >> > > >> >> > > > > > > > forth and back, once from VM to TM, and
>> > >> then back from
>> > >> > > >> >> TM to VM again?
>> > >> > > >> >> > > > > > > >
>> > >> > > >> >> > > > > > > > If you need to know in jthread_attach,
>> > >> which particular
>> > >> > > >> >> VM vm_attach()
>> > >> > > >> >> > > > > > > > event is coming from, you could have
>> > >> vm_attach like
>> > >> > > >> >> > > > > > > > vm_attach(JNIEnv* currentThreadEnv,
>> JNIEnv**
>> > >> > > >> >> newThreadEnv).
>> > >> > > >> >> > > > > > > I'm a little bit confused.....Current
>> thread
>> > >> hasn't been
>> > >> > > >> >> attached yet.
>> > >> > > >> >> > > > > > > So there is no JNIEnv for it yet. How
>> it can
>> > >> be passed as
>> > >> > > >> >> the first
>> > >> > > >> >> > > > > > > parameter to vm_attach()?
>> > >> > > >> >> > > > > > >
>> > >> > > >> >> > > > > > > > Then you will be always able to get the
>> > >> JavaVM from the
>> > >> > > >> >> JNIEnv.
>> > >> > > >> >> > > > > > > > The only difference is that you are
>> > >> currently doing
>> > >> > > >> >> JNIEnv->JavaVM
>> > >> > > >> >> > > > > > > > conversion in the VMThreadManager,
>> but why
>> > >> can't you
>> > >> > > >> >> just do this in
>> > >> > > >> >> > > > > > > > vm_attach() without changing the
>> interface
>> > >> of the TM?
>> > >> > > >> >> > > > > > > > So far JavaVM really looks like an extra
>> > >> knowledge that
>> > >> > > >> >> TM doesn't
>> > >> > > >> >> > > > > > > > have to be aware of.
>> > >> > > >> >> > > > > > > >
>> > >> > > >> >> > > > > > > > > Moreover there is no JNIEnv when main
>> > >> thread attaches
>> > >> > > >> >> to VM. So we
>> > >> > > >> >> > > > > > > > > should either keep it as is or change
>> > >> original design
>> > >> > > >> >> of TM and attach
>> > >> > > >> >> > > > > > > > > thread to VM before attaching it to
>> TM.
>> > >> In that case
>> > >> > > >> >> we will have
>> > >> > > >> >> > > > > > > > > valid JNIEnv which can be passed to
>> > >> jthread_atatch. We
>> > >> > > >> >> need to think
>> > >> > > >> >> > > > > > > > > over it twice before changing
>> something....
>> > >> > > >> >> > > > > > > >
>> > >> > > >> >> > > > > > > > Right. For jthread_attach, JNIenv
>> needs to
>> > >> be changed
>> > >> > > >> >> from being input
>> > >> > > >> >> > > > > > > > parameter to being the output parameter.
>> > >> The way how
>> > >> > > >> >> JNIenv is
>> > >> > > >> >> > > > > > > > obtained by TM should be vm_attach()
>> event.
>> > >> > > >> >> > > > > > > OK, JNIEnv is output parameter. And it
>> > >> obtained by
>> > >> > > >> >> vm_attach(). This
>> > >> > > >> >> > > > > > > is exactly like I do in the patch. What I
>> > >> don't understand
>> > >> > > >> >> is how
>> > >> > > >> >> > > > > > > jthread_attach knows to which VM the
>> thread
>> > >> should be
>> > >> > > >> >> attached? Do you
>> > >> > > >> >> > > > > > > suggest calling vm_attach first to create
>> > >> JNIEnv it pass
>> > >> > > >> >> it to
>> > >> > > >> >> > > > > > > jthread_attach?
>> > >> > > >> >> > > > > > >
>> > >> > > >> >> > > > > > > >
>> > >> > > >> >> > > > > > > > >
>> > >> > > >> >> > > > > > > > >
>> > >> > > >> >> > > > > > > > >
>> > >> > > >> >> > > > > > > > > >
>> > >> > > >> >> > > > > > > > > >
>> > >> > > >> >> > > > > > > > > > 4) Original classlib hythread do
>> not use
>> > >> > > >> >> hythread_library_t in arguments,
>> > >> > > >> >> > > > > > > > > > It uses following code:
>> > >> > > >> >> > > > > > > > > >
>> > >> > > >> >> > > > > > > > > > hythread_library_t lib =
>> GLOBAL_DATA
>> > >> > > >> >> (default_library);
>> > >> > > >> >> > > > > > > > > > or
>> > >> > > >> >> > > > > > > > > > hythread_library_t library =
>> thread-
>> > >> >library;
>> > >> > > >> >> > > > > > > > > >
>> > >> > > >> >> > > > > > > > > > So could you please use the same
>> > >> mechanism and
>> > >> > > >> >> remove hythread_*_ex >functions.
>> > >> > > >> >> > > > > > > > > Let's see if classlib's hythread needs
>> > >> changing first.
>> > >> > > >> >> It seems for me
>> > >> > > >> >> > > > > > > > > such code prevents us from having
>> multi VM.
>> > >> > > >> >> > > > > > > > >
>> > >> > > >> >> > > > > > > > > >
>> > >> > > >> >> > > > > > > > > > 5. You introduce more then one jni
>> > >> env, but still
>> > >> > > >> >> use global variable for it.
>> > >> > > >> >> > > > > > > > > > So all changes like following:
>> > >> > > >> >> > > > > > > > > > - JNIEnv *jenv = (JNIEnv*)
>> > >> jni_native_intf;
>> > >> > > >> >> > > > > > > > > > + JNIEnv *jenv = jni_native_intf;
>> > >> > > >> >> > > > > > > > > >
>> > >> > > >> >> > > > > > > > > > should be like:
>> > >> > > >> >> > > > > > > > > > - JNIEnv *jenv = (JNIEnv*)
>> > >> jni_native_intf;
>> > >> > > >> >> > > > > > > > > > + JNIEnv *jenv = get_jni_env
>> > >> (jthread_self());
>> > >> > > >> >> > > > > > > > >
>> > >> > > >> >> > > > > > > > > Ok, I see. I agree that global
>> > >> jni_native_intf should
>> > >> > > >> >> not be used.
>> > >> > > >> >> > > > > > > > > There was simple reason why I altered
>> > >> such lines.
>> > >> > > >> >> Because I changed
>> > >> > > >> >> > > > > > > > > the type of jni_native_intf and no
>> > >> casting operator
>> > >> > > >> >> is needed now. To
>> > >> > > >> >> > > > > > > > > be honest I think get_jni_env
>> > >> (jthread_self()) can be
>> > >> > > >> >> good as temporary
>> > >> > > >> >> > > > > > > > > solution only. Lets wait for design of
>> > >> multi VM and
>> > >> > > >> >> fix it according
>> > >> > > >> >> > > > > > > > > to it.
>> > >> > > >> >> > > > > > > >
>> > >> > > >> >> > > > > > > > While we are in JNI code, we always have
>> > >> the JNIenv (at
>> > >> > > >> >> least
>> > >> > > >> >> > > > > > > > initially it comes from Java code).
>> If we
>> > >> consider VM
>> > >> > > >> >> code as if it
>> > >> > > >> >> > > > > > > > was a JNI application, then it seems
>> like
>> > >> we should be
>> > >> > > >> >> just passing
>> > >> > > >> >> > > > > > > > JNIEnv as a parameter to all
>> functions in
>> > >> VM. Or, we can
>> > >> > > >> >> be taking it
>> > >> > > >> >> > > > > > > > from TLS (via jthread_self()), depending
>> > >> on which way is
>> > >> > > >> >> faster...
>> > >> > > >> >> > > > > > > Agree.
>> > >> > > >> >> > > > > > >
>> > >> > > >> >> > > > > > > >
>> > >> > > >> >> > > > > > > > >
>> > >> > > >> >> > > > > > > > > >
>> > >> > > >> >> > > > > > > > > > 6). And small remarks:
>> > >> > > >> >> > > > > > > > > > +jint vm_init1(JavaVM_Internal *
>> java_vm,
>> > >> > > >> >> JavaVMInitArgs * vm_arguments);
>> > >> > > >> >> > > > > > > > > > +jint vm_init2(JNIEnv_Internal *
>> > >> jni_env);
>> > >> > > >> >> > > > > > > > > > Could you make names more
>> meaningful,
>> > >> then 1,2,3...?
>> > >> > > >> >> > > > > > > > > Ok, will do that.
>> > >> > > >> >> > > > > > > > >
>> > >> > > >> >> > > > > > > > > >
>> > >> > > >> >> > > > > > > > > > class VM_thread {
>> > >> > > >> >> > > > > > > > > > ...
>> > >> > > >> >> > > > > > > > > > + JNIEnv_Internal * jni_env;
>> > >> > > >> >> > > > > > > > > > The jthread already has the jni_env
>> > >> pointer, you do
>> > >> > > >> >> not need to
>> > >> > > >> >> > > > > > > > > > duplicate it here.
>> > >> > > >> >> > > > > > > > > > forexample by using
>> > >> > > >> >> jthread_get_JNI_env(jthread_self());
>> > >> > > >> >> > > > > > > > >
>> > >> > > >> >> > > > > > > > > Yes I know. I don't see any problems
>> > >> here. Some times
>> > >> > > >> >> it is much more
>> > >> > > >> >> > > > > > > > > convenient to get JNIEnv from
>> VM_thread
>> > >> structure (and
>> > >> > > >> >> faster) instead
>> > >> > > >> >> > > > > > > > > of doing jthread_get_JNI_env
>> (jthread_self
>> > >> ()). So I
>> > >> > > >> >> need strong
>> > >> > > >> >> > > > > > > > > arguments for removing it. Again it
>> > >> seems that should
>> > >> > > >> >> be addressed in
>> > >> > > >> >> > > > > > > > > design of multi VM. So lets forget
>> about
>> > >> it for a
>> > >> > > >> >> while...
>> > >> > > >> >> > > > > > > >
>> > >> > > >> >> > > > > > > > I think that the data duplication would
>> > >> always serve as
>> > >> > > >> >> a potential
>> > >> > > >> >> > > > > > > > source of errors - while updating one
>> copy
>> > >> of object,
>> > >> > > >> >> you may forget
>> > >> > > >> >> > > > > > > > to update the other, often resulting
>> into
>> > >> a strange
>> > >> > > >> >> behavior of the
>> > >> > > >> >> > > > > > > > whole application. Let's see what are
>> the
>> > >> specific
>> > >> > > >> >> performance
>> > >> > > >> >> > > > > > > > concerns that have to be addressed.
>> To get
>> > >> VM_thread
>> > >> > > >> >> structure, you
>> > >> > > >> >> > > > > > > > would eventually go to the TLS, just
>> like
>> > >> > > >> >> > > > > > > > jthread_get_JNI_env(jthread_self()
>> would do.
>> > >> > > >> >> > > > > > > If there is already VM_thread structure
>> for
>> > >> some reasons
>> > >> > > >> >> then there
>> > >> > > >> >> > > > > > > will be no extra access to TLS. It is
>> > >> definitely much
>> > >> > > >> more in
>> > >> > > >> >> > > > > > > jthread_get_JNI_env(jthread_self() than
>> just
>> > >> one TLS
>> > >> > > >> >> access and one
>> > >> > > >> >> > > > > > > dereferncing. I don't think it is a really
>> > >> big problem
>> > >> > > >> >> now. Do you
>> > >> > > >> >> > > > > > > agree to look at this later. I guess
>> multi VM
>> > >> > > >> >> implementation will
>> > >> > > >> >> > > > > > > alter it in any case.
>> > >> > > >> >> > > > > > >
>> > >> > > >> >> > > > > > > Thanks
>> > >> > > >> >> > > > > > > Evgueni
>> > >> > > >> >> > > > > > >
>> > >> > > >> >> > > > > > > >
>> > >> > > >> >> > > > > > > > Thanks,
>> > >> > > >> >> > > > > > > > Andrey.
>> > >> > > >> >> > > > > > > >
>> > >> > > >> >> > > > > > > > >
>> > >> > > >> >> > > > > > > > > Evgueni
>> > >> > > >> >> > > > > > > > > >
>> > >> > > >> >> > > > > > > > > > Thanks
>> > >> > > >> >> > > > > > > > > > Artem
>> > >> > > >> >> > > > > > > > > >
>> > >> > > >> >> > > > > > > > > > On 9/28/06, Evgueni Brevnov
>> > >> > > >> >> <ev...@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.
>> > >> > > >> >> > > > > > > > > > >
>> > >> > > >> >> > > > > > > > > > > Thanks
>> > >> > > >> >> > > > > > > > > > > Evgueni
>> > >> > > >> >> > > > > > > > > > >
>> > >> > > >> >> > > > > > > > > > > On 9/28/06, Geir Magnusson Jr.
>> > >> <ge...@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
>> > >> > > >> >> <we...@gmail.com> wrote:
>> > >> > > >> >> > > > > > > > > > > > >> On 9/26/06, Evgueni Brevnov
>> > >> > > >> >> <ev...@gmail.com> wrote:
>> > >> > > >> >> > > > > > > > > > > > >> >
>> > >> > > >> >> > > > > > > > > > > > >> > On 9/27/06, Andrey
>> Chernyshev
>> > >> > > >> >> <a....@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
>> > >> > > >> >> > > > > > > > > > >
>> > >> > > >> >> > > > > > > > > > >
>> > >> > > >> >> > > > > > > > > >
>> > >> > > >> >> > > > > > > > > >
>> > >> > > >> >>
>> > >>
>> ---------------------------------------------------------------------
>> > >> > > >> >> > > > > > > > > > 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
>> > >> > > >> >> > > > > > > > >
>> > >> > > >> >> > > > > > > > >
>> > >> > > >> >> > > > > > > >
>> > >> > > >> >> > > > > > > >
>> > >> > > >> >> > > > > > > > --
>> > >> > > >> >> > > > > > > > Andrey Chernyshev
>> > >> > > >> >> > > > > > > > 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
>> > >> > > >> >> > > > > >
>> > >> > > >> >> > > > > >
>> > >> > > >> >> > > > >
>> > >> > > >> >> > > > >
>> > >> > > >> >> > > > > --
>> > >> > > >> >> > > > > Andrey Chernyshev
>> > >> > > >> >> > > > > 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
>> > >> > > >> >> > > >
>> > >> > > >> >> > > >
>> > >> > > >> >> > >
>> > >> > > >> >> > >
>> > >> > > >> >> > > --
>> > >> > > >> >> > > Andrey Chernyshev
>> > >> > > >> >> > > 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
>> > >> > > >>
>> > >> > > >>
>> > >> > > >
>> > >> > > >
>> > >>
>> ---------------------------------------------------------------------
>> > >> > > > 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
>> > >
>> >
>> >
>> >
>> ---------------------------------------------------------------------
>> > 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
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
Posted by Evgueni Brevnov <ev...@gmail.com>.
BTW, could you verify the right patch for tests was used? It should be
tests.final.2.patch...... Sorry for the mess with patches....
Evgueni
On 10/9/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> I put debug printing into test_ti_instrum.c and attached it to JIRA.
> Could you run it on your machine and send me console output.
>
> Evgueni
>
> On 10/9/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> > I keep getting a failure when running the tests -
> >
> > test_jthread_get_all-threads failling the assertion at
> > test_ti_instrum.c:80
> >
> > geir
> >
> > On Oct 8, 2006, at 7:19 AM, Evgueni Brevnov wrote:
> >
> > > While running cunit on Linux it turned out one test case fails some
> > > time. The fix is in tests.final.2.patch.
> > >
> > > So the last versions to be committed:
> > > invocation_api.final.patch
> > > build.final.2.patch
> > > tests.final.2.patch
> > >
> > > Evgueni
> > >
> > >
> > > On 10/8/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> > >> I mahaged to resolve the problem on Linux.... will update
> > >> build.final.patch with build.final.2.patch in a while
> > >>
> > >> On 10/8/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> > >> > Hi,
> > >> >
> > >> > Oh! Ooh! I did that..... I passed cunit, somke, kernel tests on
> > >> > Windows and smoke, kernel tests on Linux. Unfortunately I failed to
> > >> > link cunit tests on Linux so far. So I disabled cunit on Linux
> > >> until
> > >> > the problem is solved. I believe it is acceptable as short term
> > >> > solution. I found several problems in cunit tests. I will come
> > >> up with
> > >> > my findings later (not today).
> > >> >
> > >> > Use latest patches from HARMONY-1582. They are marked as final.
> > >> There
> > >> > are three patches. One for build module, one for cunit tests and
> > >> one
> > >> > for VM itself.
> > >> >
> > >> > Thanks
> > >> > Evgueni
> > >> >
> > >> >
> > >> > On 10/6/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> > >> > > Nooooooo! LOL
> > >> > >
> > >> > > I'm here waiting - This will unblock a whole bunch of things :)
> > >> > >
> > >> > > Thanks for the effort
> > >> > >
> > >> > > Evgueni Brevnov wrote:
> > >> > > > Geir,
> > >> > > >
> > >> > > > That's terrible. We have power outage....servers are down. I
> > >> can't
> > >> > > > send the patches now.... will do it tomorrow
> > >> > > >
> > >> > > > Evgueni
> > >> > > > On 10/5/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> > >> > > >> woo hoo! here we go...
> > >> > > >>
> > >> > > >>
> > >> > > >> Andrey Chernyshev wrote:
> > >> > > >> > Hi Evgueni,
> > >> > > >> >
> > >> > > >> > On 10/4/06, Evgueni Brevnov <ev...@gmail.com>
> > >> wrote:
> > >> > > >> >> Hi All,
> > >> > > >> >>
> > >> > > >> >> I have attached updated patch to the JIRA. It should
> > >> resolve remain
> > >> > > >> >> concerns. Andrey, could you give a green light now?
> > >> > > >> >
> > >> > > >> > Thanks for updating the patch! I agree it it can be
> > >> committed, at
> > >> > > >> > least signatures look good. 5 revisions seem like more
> > >> than enough :).
> > >> > > >> > Anyways, I think the remaining issues can be resolved
> > >> with additional
> > >> > > >> > patches. Thanks again for the good work and your patience.
> > >> > > >> >
> > >> > > >> > Thanks,
> > >> > > >> > Andrey.
> > >> > > >> >
> > >> > > >> >>
> > >> > > >> >> Thanks
> > >> > > >> >> Evgueni
> > >> > > >> >>
> > >> > > >> >> On 10/4/06, Evgueni Brevnov <ev...@gmail.com>
> > >> wrote:
> > >> > > >> >> > Andrey,
> > >> > > >> >> >
> > >> > > >> >> > I see your points. I think both approaches have
> > >> advantages and
> > >> > > >> >> > disadvantages. I think it is quite hard to say which
> > >> approach is
> > >> > > >> >> > better until we play with one VM only. I still feel
> > >> like introducing
> > >> > > >> >> > one more dependence is better than spreading code
> > >> which deals with
> > >> > > >> >> > attachment among VM and TM. We really get stuck. OK,
> > >> just because I
> > >> > > >> >> > want to move forward I will do required changes to remove
> > >> > > >> >> > vm_create_jthread from TM. I believe that will resolve
> > >> all our
> > >> > > >> >> > disagreements and the patch will be applied soon.
> > >> > > >> >> >
> > >> > > >> >> >
> > >> > > >> >> > Thanks
> > >> > > >> >> > Evgueni.
> > >> > > >> >> >
> > >> > > >> >> > On 10/4/06, Andrey Chernyshev
> > >> <a....@gmail.com> wrote:
> > >> > > >> >> > > On 10/3/06, Evgueni Brevnov
> > >> <ev...@gmail.com> wrote:
> > >> > > >> >> > > > On 10/3/06, Andrey Chernyshev
> > >> <a....@gmail.com> wrote:
> > >> > > >> >> > > > > On 10/2/06, Evgueni Brevnov
> > >> <ev...@gmail.com> wrote:
> > >> > > >> >> > > > > > Andrey,
> > >> > > >> >> > > > > >
> > >> > > >> >> > > > > > Just to be clear.... I agree with you it is more
> > >> > > >> convenient if
> > >> > > >> >> > > > > > jthread_create takes JNIEnv instead of JavaVM. It
> > >> > > >> reflects that
> > >> > > >> >> > > > > > current thread has been attached already. Do
> > >> you think it
> > >> > > >> >> makes sense
> > >> > > >> >> > > > > > to get rid of JNIEnv and use
> > >> jthread_get_JNI_env in that
> > >> > > >> case?
> > >> > > >> >> > > > >
> > >> > > >> >> > > > > The jthread_* layer is designed like if it were
> > >> a regular JNI
> > >> > > >> >> > > > > application which is meant to be called from the
> > >> Java code,
> > >> > > >> hence
> > >> > > >> >> > > > > every function on that layer receives JNIenv. We
> > >> can probably
> > >> > > >> >> get rid
> > >> > > >> >> > > > > of the JNEnv parameter for jthread_* functions,
> > >> assuming that
> > >> > > >> >> TM can
> > >> > > >> >> > > > > always extract JNIenv for the current thread with
> > >> > > >> >> > > > > jthread_get_JNI_env().
> > >> > > >> >> > > > > My only concern would be the performance - once
> > >> the JNIenv is
> > >> > > >> >> already
> > >> > > >> >> > > > > known for the native part of the kernel classes
> > >> impl, it
> > >> > > >> must be
> > >> > > >> >> > > > > cheaper to pass JNIEnv to TM as an extra
> > >> parameter rather than
> > >> > > >> >> extract
> > >> > > >> >> > > > > it from the TLS again.
> > >> > > >> >> > > > > Other than that, I see no strong advantages in
> > >> keeping JNIEnv
> > >> > > >> >> parameter.
> > >> > > >> >> > > > >
> > >> > > >> >> > > > >
> > >> > > >> >> > > > > > Regarding jthread_attach. I still didn't get
> > >> your point....
> > >> > > >> >> Clarify it
> > >> > > >> >> > > > > > please if you think jhread_attach should be
> > >> modified.
> > >> > > >> >> > > > >
> > >> > > >> >> > > > > Sorry for being not clear: I think for
> > >> jthread_attach, we have
> > >> > > >> >> two options:
> > >> > > >> >> > > > > 1) Make JNIEnv input parameter - it must be new
> > >> JNIEnv that VM
> > >> > > >> >> > > > > pre-allocates for the new Java thread.
> > >> jthread_attach
> > >> > > >> would just
> > >> > > >> >> > > > > associate it with the current thread.
> > >> > > >> >> > > > >
> > >> > > >> >> > > > > 2) Obtain JNIEnv via vm_attach() callback. In
> > >> this case, if
> > >> > > >> >> > > > > vm_attach() callback implementation needs to
> > >> know for which
> > >> > > >> >> JavaVM new
> > >> > > >> >> > > > > JNIenv has to be allocated, then we'll need to
> > >> add JavaVM as
> > >> > > >> >> input
> > >> > > >> >> > > > > parameter for jthread_attach().
> > >> > > >> >> > > > > I think both options should be fine, (1) would
> > >> probably
> > >> > > >> keep TM
> > >> > > >> >> > > > > interface a bit lighter, though (2) may look
> > >> more closer to
> > >> > > >> >> the JNI
> > >> > > >> >> > > > > invocation API idea.
> > >> > > >> >> > > > > So I think adding JavaVM specifically for
> > >> jthread_attach
> > >> > > >> may make
> > >> > > >> >> > > > > sense given the explanation you provided earlier.
> > >> > > >> >> > > > >
> > >> > > >> >> > > > > The concern I would have regarding the proposed
> > >> jthread_attach
> > >> > > >> >> > > > > implementation is a call to vm_create_jthread()
> > >> - this call
> > >> > > >> >> introduces
> > >> > > >> >> > > > > an extra dependency of TM on vmcore that I'd
> > >> prefer to be
> > >> > > >> >> avoided. In
> > >> > > >> >> > > > > the original version, jthread_attach() was
> > >> taking jthread
> > >> > > >> >> argument of
> > >> > > >> >> > > > > the already prepared j.l.Thread.
> > >> > > >> >> > > >
> > >> > > >> >> > > > I understand your concern. Unfortunately I don't
> > >> see what we
> > >> > > >> can do
> > >> > > >> >> > > > here. Let me explain. In the beginning you have an
> > >> unattached
> > >> > > >> >> native
> > >> > > >> >> > > > thread. To be able to call java code (which is
> > >> required for
> > >> > > >> >> > > > constructing j.l.Thread instance) the thread
> > >> should be attached
> > >> > > >> >> first.
> > >> > > >> >> > > > To be specific it should be attached to VM by
> > >> calling vm_attach
> > >> > > >> >> which
> > >> > > >> >> > > > will return a valid JNIEnv It is valid to use JNI
> > >> from that
> > >> > > >> moment.
> > >> > > >> >> > > > Obtained JNIEnv can be used to execute java code
> > >> and create
> > >> > > >> >> j.l.Thread
> > >> > > >> >> > > > instance. Since we do vm_attach in jthread_attach
> > >> we need to do
> > >> > > >> >> > > > vm_create_jthread inside jthread_atach as well.
> > >> > > >> >> > > > Of course it can be an alternative to do vm_attach
> > >> and
> > >> > > >> >> > > > vm_create_jthread outside of TM right before
> > >> jthread_attach.
> > >> > > >> >> Sure it
> > >> > > >> >> > > > will reduce one dependence between VM and TM. But
> > >> it seems like
> > >> > > >> >> > > > artificial action for me just because of
> > >> dependency....
> > >> > > >> >> > >
> > >> > > >> >> > > Why do you think it is artificial? I would rather
> > >> prefer not to
> > >> > > >> throw
> > >> > > >> >> > > vm_attach event from the jthread_attach() call at
> > >> all than to add
> > >> > > >> >> > > extra dependency. The idea of jthread layer is a
> > >> Java face to
> > >> > > >> >> > > hythread, it is meant to know either a little or
> > >> nothing about the
> > >> > > >> >> > > rest of VM. It may be logical to throw vm_attach
> > >> call from the
> > >> > > >> newly
> > >> > > >> >> > > created thread, because there is no other way to let
> > >> know VM
> > >> > > >> the new
> > >> > > >> >> > > thread is created. VM attach is a different case -
> > >> VM already
> > >> > > >> knows
> > >> > > >> >> > > about new Java thread at the time of the
> > >> AttachCurrentThread call.
> > >> > > >> >> > >
> > >> > > >> >> > > >
> > >> > > >> >> > > > > Do you think it makes sense to replace a single
> > >> jthread
> > >> > > >> >> parameter with
> > >> > > >> >> > > > > a variety of stuff (like thread group, name)? It
> > >> seems the
> > >> > > >> only
> > >> > > >> >> > > > > purpose of at these args is to be passed back to
> > >> VM for
> > >> > > >> >> > > > > vm_jthread_create(). I would suggest to change
> > >> this and try
> > >> > > >> doing
> > >> > > >> >> > > > > either of:
> > >> > > >> >> > > > > 1) Make signature of jthread_attach with 3 args,
> > >> JavaVM,
> > >> > > >> >> jthread and the daemon.
> > >> > > >> >> > > > Why do you want to pass daemon to TM but thread's
> > >> name and
> > >> > > >> >> group. Just
> > >> > > >> >> > > > because current TM doesn't need such information?
> > >> What if it is
> > >> > > >> >> > > > required to get thread name later? Say by introducing
> > >> > > >> >> > >
> > >> > > >> >> > > I imagine you need a daemon attribute since the TM
> > >> is still
> > >> > > >> managing
> > >> > > >> >> > > the thread daemonality. TM is not managing thread
> > >> name and group -
> > >> > > >> >> > > they are all kept on the Java level, hence passing
> > >> them may be
> > >> > > >> >> > > excessive.
> > >> > > >> >> > >
> > >> > > >> >> > > > jthread_get_name... What will you do in that case?
> > >> Let me
> > >> > > >> guess you
> > >> > > >> >> > > > will call j.l.Thread.getName. Right. Ok! In that
> > >> case I see no
> > >> > > >> >> > > > problems to call j.l.Thread.isDaemon. Do you
> > >> agree? So it
> > >> > > >> doesn't
> > >> > > >> >> > >
> > >> > > >> >> > > As I suggested earlier, the best way to handle
> > >> daemonality would
> > >> > > >> >> > > probably be in pure Java - in j.l.Thread (or
> > >> > > >> j.l.VMThreadManager) or
> > >> > > >> >> > > whatever. You already lifted it up to the jthread
> > >> level, but
> > >> > > >> what if
> > >> > > >> >> > > we can go a little bit higher...
> > >> > > >> >> > >
> > >> > > >> >> > > > seems to be a good design to pass only part of the
> > >> > > >> information to
> > >> > > >> >> > > > jthread_atach. Lets look at the signature of
> > >> > > >> >> AttachCurrentThread. It
> > >> > > >> >> > > > takes exactly these three parameters (daemon,
> > >> name, group)
> > >> > > >> >> passed as a
> > >> > > >> >> > > > structure. I was thinking about having exactly the
> > >> same
> > >> > > >> >> structure as
> > >> > > >> >> > > > third parameter of jthread_attach but it occured
> > >> to be more
> > >> > > >> >> convinient
> > >> > > >> >> > > > to pass them seperatly. Although I don't see
> > >> strong reasons
> > >> > > >> against
> > >> > > >> >> > > > having a structure a third parameter.
> > >> > > >> >> > >
> > >> > > >> >> > > I see. Acually, I would love to keep the
> > >> jthread_attach func-ty at
> > >> > > >> >> the
> > >> > > >> >> > > minimum level which will be needed to handle the
> > >> only data that TM
> > >> > > >> >> > > should be aware of. We need a formal boundary
> > >> between jthread
> > >> > > >> layer
> > >> > > >> >> > > and vmcore (otherwise jthread won't have a much of
> > >> sense, one may
> > >> > > >> >> > > consider it just as a convenience set of functions
> > >> in vmcore which
> > >> > > >> >> are
> > >> > > >> >> > > doing something with threading).
> > >> > > >> >> > >
> > >> > > >> >> > > >
> > >> > > >> >> > > > > 2) Move the implementation of vm_create_jtrhead
> > >> () to
> > >> > > >> >> > > > > thread_java_basic.c - could it be written in
> > >> pure JNI without
> > >> > > >> >> using
> > >> > > >> >> > > > > internal VM API like class_alloc_new_object()?
> > >> > > >> >> > > >
> > >> > > >> >> > > > Yes, this can be done but it doesn't fix the
> > >> problem. You still
> > >> > > >> >> need
> > >> > > >> >> > > > to know about internal constructor of j.l.Thread
> > >> > > >> >> > >
> > >> > > >> >> > > That's bad. Given what you said, now it seems that
> > >> the most
> > >> > > >> >> preferable
> > >> > > >> >> > > sequence for AttachCurrentThread impl still would be
> > >> like:
> > >> > > >> >> > > JNIEnv = vm_attach();
> > >> > > >> >> > > jthread = create_jthread(JNIenv)
> > >> > > >> >> > > jthread_attach(JNIEnv, jthread) // stores JNIEnv and
> > >> Hythread into
> > >> > > >> >> > > TLS, doesn't call vm_attach any longer.
> > >> > > >> >> > > - this is almost what we had from the beginning...
> > >> > > >> >> > >
> > >> > > >> >> > > Thanks,
> > >> > > >> >> > > Andrey.
> > >> > > >> >> > >
> > >> > > >> >> > > >
> > >> > > >> >> > > >
> > >> > > >> >> > > > Thanks
> > >> > > >> >> > > > Evgueni
> > >> > > >> >> > > > >
> > >> > > >> >> > > > >
> > >> > > >> >> > > > > Thanks,
> > >> > > >> >> > > > > Andrey.
> > >> > > >> >> > > > >
> > >> > > >> >> > > > > >
> > >> > > >> >> > > > > > Thank you
> > >> > > >> >> > > > > > Evgueni
> > >> > > >> >> > > > > >
> > >> > > >> >> > > > > > On 10/2/06, Evgueni Brevnov
> > >> <ev...@gmail.com>
> > >> > > >> wrote:
> > >> > > >> >> > > > > > > On 9/29/06, Andrey Chernyshev
> > >> <a....@gmail.com>
> > >> > > >> >> wrote:
> > >> > > >> >> > > > > > > > On 9/29/06, Evgueni Brevnov
> > >> <ev...@gmail.com>
> > >> > > >> >> wrote:
> > >> > > >> >> > > > > > > > > Artem,
> > >> > > >> >> > > > > > > > >
> > >> > > >> >> > > > > > > > > Thank you for your feedback.... find my
> > >> inlined.....
> > >> > > >> >> > > > > > > > >
> > >> > > >> >> > > > > > > > > On 9/29/06, Artem Aliev
> > >> <ar...@gmail.com> wrote:
> > >> > > >> >> > > > > > > > > > Evgueni,
> > >> > > >> >> > > > > > > > > >
> > >> > > >> >> > > > > > > > > > I got most of your changes, but still
> > >> disagree
> > >> > > >> with all
> > >> > > >> >> > > > > > > > > > hythread/jthread interface changes.
> > >> Could leave
> > >> > > >> >> interface unchanged.
> > >> > > >> >> > > > > > > > > > See following possible solutions, that
> > >> could solve
> > >> > > >> >> the same problems
> > >> > > >> >> > > > > > > > > > without interface changes.
> > >> > > >> >> > > > > > > > > >
> > >> > > >> >> > > > > > > > > >
> > >> > > >> >> > > > > > > > > > 1) daemon attribute is a java
> > >> specific. (Andrey
> > >> > > >> >> mentioned this already).
> > >> > > >> >> > > > > > > > > > Could you please move it back. to
> > >> the jthread
> > >> > > >> >> layer. It is better
> > >> > > >> >> > > > > > > > > > to rename
> > >> > > >> >> > > > > > > > > >
> > >> hythread_wait_for_all_nondaemon_threads() to
> > >> > > >> >> > > > > > > > > > jthread_wait_for_all_nondaemon_threads().
> > >> > > >> >> > > > > > > > > Ok, I see no problems to move "daemon"
> > >> to java layer.
> > >> > > >> >> In that case:
> > >> > > >> >> > > > > > > > > 1) I will move
> > >> > > >> >> hythread_wait_for_all_nondaemon_threads() from
> > >> > > >> >> > > > > > > > > thread_init.c to one which implements
> > >> java layer.
> > >> > > >> >> > > > > > > > > 2) I will move daemon field from
> > >> HyThread structure.
> > >> > > >> >> > > > > > > > >
> > >> > > >> >> > > > > > > > > Agree?
> > >> > > >> >> > > > > > > >
> > >> > > >> >> > > > > > > > Sounds good to me.
> > >> > > >> >> > > > > > >
> > >> > > >> >> > > > > > > OK, will do that.
> > >> > > >> >> > > > > > >
> > >> > > >> >> > > > > > > >
> > >> > > >> >> > > > > > > >
> > >> > > >> >> > > > > > > > >
> > >> > > >> >> > > > > > > > > >
> > >> > > >> >> > > > > > > > > > 2) JavaVM could be retrieved from
> > >> JNIEnv by
> > >> > > >> >> jni_get_java_vm(). So
> > >> > > >> >> > > > > > > > > > let the jthread_create() and others to
> > >> use JNIEnv
> > >> > > >> >> (that is passed from
> > >> > > >> >> > > > > > > > > > java native method).
> > >> > > >> >> > > > > > > > > > The vm_attach could get old JNI env
> > >> and create new
> > >> > > >> >> one for the new thread.
> > >> > > >> >> > > > > > > > > > The first JNIEnv is created in
> > >> CreateVM call and
> > >> > > >> >> could be passed to
> > >> > > >> >> > > > > > > > > > the first thread at startup.
> > >> > > >> >> > > > > > > > > No, no, no. I completely disagree with
> > >> that!!! Why do
> > >> > > >> >> you like JNIEnv
> > >> > > >> >> > > > > > > > > but JavaVM. Why do you think that
> > >> passing JavaVM
> > >> > > >> >> instead of JNIEnv
> > >> > > >> >> > > > > > > > > makes TM less modular? I don't see any
> > >> difference
> > >> > > >> >> here.... It seems
> > >> > > >> >> > > > > > > > > for me like a big big hack to grab
> > >> JNIEnv from another
> > >> > > >> >> thread and pass
> > >> > > >> >> > > > > > > > > it to jthread_attach to perform
> > >> operations in the
> > >> > > >> >> current thread.
> > >> > > >> >> > > > > > > >
> > >> > > >> >> > > > > > > > TM needs to know JNIEnv, mainly for
> > >> managing the
> > >> > > >> >> references to
> > >> > > >> >> > > > > > > > objects, throwing exceptions and calling
> > >> run() method of
> > >> > > >> >> a new thread.
> > >> > > >> >> > > > > > > > JNI spec proposes that JNIEnv is valid
> > >> within the given
> > >> > > >> >> thread, this
> > >> > > >> >> > > > > > > > is why TM holds the JNIEnv pointer at the
> > >> moment. This
> > >> > > >> >> is why TM likes
> > >> > > >> >> > > > > > > > the JNIEnv.
> > >> > > >> >> > > > > > > >
> > >> > > >> >> > > > > > > > Having the JNIEnv, one is able to get
> > >> JavaVM but not
> > >> > > >> >> vise versa. This
> > >> > > >> >> > > > > > > > is why TM doesn't like the JavaVM :)
> > >> > > >> >> > > > > > > I see your point. Only one note this is true
> > >> for already
> > >> > > >> >> attached threads...
> > >> > > >> >> > > > > > >
> > >> > > >> >> > > > > > > >
> > >> > > >> >> > > > > > > > I agree with you that there is a design
> > >> flaw that the
> > >> > > >> >> JNIEnv is copied
> > >> > > >> >> > > > > > > > from the parent thread to a child thread
> > >> during thread
> > >> > > >> >> creation. I
> > >> > > >> >> > > > > > > > think it could be resolved via vm_attach()
> > >> hook - with
> > >> > > >> >> this event, VM
> > >> > > >> >> > > > > > > > might tell the TM what the JNIEnv pointer
> > >> for new thread
> > >> > > >> >> should be. I
> > >> > > >> >> > > > > > > > think you did that by extending the
> > >> vm_attach() call
> > >> > > >> >> with the JNIEnv**
> > >> > > >> >> > > > > > > > argument.
> > >> > > >> >> > > > > > > >
> > >> > > >> >> > > > > > > > What is not completely clear is, why do
> > >> you have to pass
> > >> > > >> >> the JavaVM
> > >> > > >> >> > > > > > > > forth and back, once from VM to TM, and
> > >> then back from
> > >> > > >> >> TM to VM again?
> > >> > > >> >> > > > > > > >
> > >> > > >> >> > > > > > > > If you need to know in jthread_attach,
> > >> which particular
> > >> > > >> >> VM vm_attach()
> > >> > > >> >> > > > > > > > event is coming from, you could have
> > >> vm_attach like
> > >> > > >> >> > > > > > > > vm_attach(JNIEnv* currentThreadEnv, JNIEnv**
> > >> > > >> >> newThreadEnv).
> > >> > > >> >> > > > > > > I'm a little bit confused.....Current thread
> > >> hasn't been
> > >> > > >> >> attached yet.
> > >> > > >> >> > > > > > > So there is no JNIEnv for it yet. How it can
> > >> be passed as
> > >> > > >> >> the first
> > >> > > >> >> > > > > > > parameter to vm_attach()?
> > >> > > >> >> > > > > > >
> > >> > > >> >> > > > > > > > Then you will be always able to get the
> > >> JavaVM from the
> > >> > > >> >> JNIEnv.
> > >> > > >> >> > > > > > > > The only difference is that you are
> > >> currently doing
> > >> > > >> >> JNIEnv->JavaVM
> > >> > > >> >> > > > > > > > conversion in the VMThreadManager, but why
> > >> can't you
> > >> > > >> >> just do this in
> > >> > > >> >> > > > > > > > vm_attach() without changing the interface
> > >> of the TM?
> > >> > > >> >> > > > > > > > So far JavaVM really looks like an extra
> > >> knowledge that
> > >> > > >> >> TM doesn't
> > >> > > >> >> > > > > > > > have to be aware of.
> > >> > > >> >> > > > > > > >
> > >> > > >> >> > > > > > > > > Moreover there is no JNIEnv when main
> > >> thread attaches
> > >> > > >> >> to VM. So we
> > >> > > >> >> > > > > > > > > should either keep it as is or change
> > >> original design
> > >> > > >> >> of TM and attach
> > >> > > >> >> > > > > > > > > thread to VM before attaching it to TM.
> > >> In that case
> > >> > > >> >> we will have
> > >> > > >> >> > > > > > > > > valid JNIEnv which can be passed to
> > >> jthread_atatch. We
> > >> > > >> >> need to think
> > >> > > >> >> > > > > > > > > over it twice before changing something....
> > >> > > >> >> > > > > > > >
> > >> > > >> >> > > > > > > > Right. For jthread_attach, JNIenv needs to
> > >> be changed
> > >> > > >> >> from being input
> > >> > > >> >> > > > > > > > parameter to being the output parameter.
> > >> The way how
> > >> > > >> >> JNIenv is
> > >> > > >> >> > > > > > > > obtained by TM should be vm_attach() event.
> > >> > > >> >> > > > > > > OK, JNIEnv is output parameter. And it
> > >> obtained by
> > >> > > >> >> vm_attach(). This
> > >> > > >> >> > > > > > > is exactly like I do in the patch. What I
> > >> don't understand
> > >> > > >> >> is how
> > >> > > >> >> > > > > > > jthread_attach knows to which VM the thread
> > >> should be
> > >> > > >> >> attached? Do you
> > >> > > >> >> > > > > > > suggest calling vm_attach first to create
> > >> JNIEnv it pass
> > >> > > >> >> it to
> > >> > > >> >> > > > > > > jthread_attach?
> > >> > > >> >> > > > > > >
> > >> > > >> >> > > > > > > >
> > >> > > >> >> > > > > > > > >
> > >> > > >> >> > > > > > > > >
> > >> > > >> >> > > > > > > > >
> > >> > > >> >> > > > > > > > > >
> > >> > > >> >> > > > > > > > > >
> > >> > > >> >> > > > > > > > > > 4) Original classlib hythread do not use
> > >> > > >> >> hythread_library_t in arguments,
> > >> > > >> >> > > > > > > > > > It uses following code:
> > >> > > >> >> > > > > > > > > >
> > >> > > >> >> > > > > > > > > > hythread_library_t lib = GLOBAL_DATA
> > >> > > >> >> (default_library);
> > >> > > >> >> > > > > > > > > > or
> > >> > > >> >> > > > > > > > > > hythread_library_t library = thread-
> > >> >library;
> > >> > > >> >> > > > > > > > > >
> > >> > > >> >> > > > > > > > > > So could you please use the same
> > >> mechanism and
> > >> > > >> >> remove hythread_*_ex >functions.
> > >> > > >> >> > > > > > > > > Let's see if classlib's hythread needs
> > >> changing first.
> > >> > > >> >> It seems for me
> > >> > > >> >> > > > > > > > > such code prevents us from having multi VM.
> > >> > > >> >> > > > > > > > >
> > >> > > >> >> > > > > > > > > >
> > >> > > >> >> > > > > > > > > > 5. You introduce more then one jni
> > >> env, but still
> > >> > > >> >> use global variable for it.
> > >> > > >> >> > > > > > > > > > So all changes like following:
> > >> > > >> >> > > > > > > > > > - JNIEnv *jenv = (JNIEnv*)
> > >> jni_native_intf;
> > >> > > >> >> > > > > > > > > > + JNIEnv *jenv = jni_native_intf;
> > >> > > >> >> > > > > > > > > >
> > >> > > >> >> > > > > > > > > > should be like:
> > >> > > >> >> > > > > > > > > > - JNIEnv *jenv = (JNIEnv*)
> > >> jni_native_intf;
> > >> > > >> >> > > > > > > > > > + JNIEnv *jenv = get_jni_env
> > >> (jthread_self());
> > >> > > >> >> > > > > > > > >
> > >> > > >> >> > > > > > > > > Ok, I see. I agree that global
> > >> jni_native_intf should
> > >> > > >> >> not be used.
> > >> > > >> >> > > > > > > > > There was simple reason why I altered
> > >> such lines.
> > >> > > >> >> Because I changed
> > >> > > >> >> > > > > > > > > the type of jni_native_intf and no
> > >> casting operator
> > >> > > >> >> is needed now. To
> > >> > > >> >> > > > > > > > > be honest I think get_jni_env
> > >> (jthread_self()) can be
> > >> > > >> >> good as temporary
> > >> > > >> >> > > > > > > > > solution only. Lets wait for design of
> > >> multi VM and
> > >> > > >> >> fix it according
> > >> > > >> >> > > > > > > > > to it.
> > >> > > >> >> > > > > > > >
> > >> > > >> >> > > > > > > > While we are in JNI code, we always have
> > >> the JNIenv (at
> > >> > > >> >> least
> > >> > > >> >> > > > > > > > initially it comes from Java code). If we
> > >> consider VM
> > >> > > >> >> code as if it
> > >> > > >> >> > > > > > > > was a JNI application, then it seems like
> > >> we should be
> > >> > > >> >> just passing
> > >> > > >> >> > > > > > > > JNIEnv as a parameter to all functions in
> > >> VM. Or, we can
> > >> > > >> >> be taking it
> > >> > > >> >> > > > > > > > from TLS (via jthread_self()), depending
> > >> on which way is
> > >> > > >> >> faster...
> > >> > > >> >> > > > > > > Agree.
> > >> > > >> >> > > > > > >
> > >> > > >> >> > > > > > > >
> > >> > > >> >> > > > > > > > >
> > >> > > >> >> > > > > > > > > >
> > >> > > >> >> > > > > > > > > > 6). And small remarks:
> > >> > > >> >> > > > > > > > > > +jint vm_init1(JavaVM_Internal * java_vm,
> > >> > > >> >> JavaVMInitArgs * vm_arguments);
> > >> > > >> >> > > > > > > > > > +jint vm_init2(JNIEnv_Internal *
> > >> jni_env);
> > >> > > >> >> > > > > > > > > > Could you make names more meaningful,
> > >> then 1,2,3...?
> > >> > > >> >> > > > > > > > > Ok, will do that.
> > >> > > >> >> > > > > > > > >
> > >> > > >> >> > > > > > > > > >
> > >> > > >> >> > > > > > > > > > class VM_thread {
> > >> > > >> >> > > > > > > > > > ...
> > >> > > >> >> > > > > > > > > > + JNIEnv_Internal * jni_env;
> > >> > > >> >> > > > > > > > > > The jthread already has the jni_env
> > >> pointer, you do
> > >> > > >> >> not need to
> > >> > > >> >> > > > > > > > > > duplicate it here.
> > >> > > >> >> > > > > > > > > > forexample by using
> > >> > > >> >> jthread_get_JNI_env(jthread_self());
> > >> > > >> >> > > > > > > > >
> > >> > > >> >> > > > > > > > > Yes I know. I don't see any problems
> > >> here. Some times
> > >> > > >> >> it is much more
> > >> > > >> >> > > > > > > > > convenient to get JNIEnv from VM_thread
> > >> structure (and
> > >> > > >> >> faster) instead
> > >> > > >> >> > > > > > > > > of doing jthread_get_JNI_env(jthread_self
> > >> ()). So I
> > >> > > >> >> need strong
> > >> > > >> >> > > > > > > > > arguments for removing it. Again it
> > >> seems that should
> > >> > > >> >> be addressed in
> > >> > > >> >> > > > > > > > > design of multi VM. So lets forget about
> > >> it for a
> > >> > > >> >> while...
> > >> > > >> >> > > > > > > >
> > >> > > >> >> > > > > > > > I think that the data duplication would
> > >> always serve as
> > >> > > >> >> a potential
> > >> > > >> >> > > > > > > > source of errors - while updating one copy
> > >> of object,
> > >> > > >> >> you may forget
> > >> > > >> >> > > > > > > > to update the other, often resulting into
> > >> a strange
> > >> > > >> >> behavior of the
> > >> > > >> >> > > > > > > > whole application. Let's see what are the
> > >> specific
> > >> > > >> >> performance
> > >> > > >> >> > > > > > > > concerns that have to be addressed. To get
> > >> VM_thread
> > >> > > >> >> structure, you
> > >> > > >> >> > > > > > > > would eventually go to the TLS, just like
> > >> > > >> >> > > > > > > > jthread_get_JNI_env(jthread_self() would do.
> > >> > > >> >> > > > > > > If there is already VM_thread structure for
> > >> some reasons
> > >> > > >> >> then there
> > >> > > >> >> > > > > > > will be no extra access to TLS. It is
> > >> definitely much
> > >> > > >> more in
> > >> > > >> >> > > > > > > jthread_get_JNI_env(jthread_self() than just
> > >> one TLS
> > >> > > >> >> access and one
> > >> > > >> >> > > > > > > dereferncing. I don't think it is a really
> > >> big problem
> > >> > > >> >> now. Do you
> > >> > > >> >> > > > > > > agree to look at this later. I guess multi VM
> > >> > > >> >> implementation will
> > >> > > >> >> > > > > > > alter it in any case.
> > >> > > >> >> > > > > > >
> > >> > > >> >> > > > > > > Thanks
> > >> > > >> >> > > > > > > Evgueni
> > >> > > >> >> > > > > > >
> > >> > > >> >> > > > > > > >
> > >> > > >> >> > > > > > > > Thanks,
> > >> > > >> >> > > > > > > > Andrey.
> > >> > > >> >> > > > > > > >
> > >> > > >> >> > > > > > > > >
> > >> > > >> >> > > > > > > > > Evgueni
> > >> > > >> >> > > > > > > > > >
> > >> > > >> >> > > > > > > > > > Thanks
> > >> > > >> >> > > > > > > > > > Artem
> > >> > > >> >> > > > > > > > > >
> > >> > > >> >> > > > > > > > > > On 9/28/06, Evgueni Brevnov
> > >> > > >> >> <ev...@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.
> > >> > > >> >> > > > > > > > > > >
> > >> > > >> >> > > > > > > > > > > Thanks
> > >> > > >> >> > > > > > > > > > > Evgueni
> > >> > > >> >> > > > > > > > > > >
> > >> > > >> >> > > > > > > > > > > On 9/28/06, Geir Magnusson Jr.
> > >> <ge...@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
> > >> > > >> >> <we...@gmail.com> wrote:
> > >> > > >> >> > > > > > > > > > > > >> On 9/26/06, Evgueni Brevnov
> > >> > > >> >> <ev...@gmail.com> wrote:
> > >> > > >> >> > > > > > > > > > > > >> >
> > >> > > >> >> > > > > > > > > > > > >> > On 9/27/06, Andrey Chernyshev
> > >> > > >> >> <a....@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
> > >> > > >> >> > > > > > > > > > >
> > >> > > >> >> > > > > > > > > > >
> > >> > > >> >> > > > > > > > > >
> > >> > > >> >> > > > > > > > > >
> > >> > > >> >>
> > >> ---------------------------------------------------------------------
> > >> > > >> >> > > > > > > > > > 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
> > >> > > >> >> > > > > > > > >
> > >> > > >> >> > > > > > > > >
> > >> > > >> >> > > > > > > >
> > >> > > >> >> > > > > > > >
> > >> > > >> >> > > > > > > > --
> > >> > > >> >> > > > > > > > Andrey Chernyshev
> > >> > > >> >> > > > > > > > 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
> > >> > > >> >> > > > > >
> > >> > > >> >> > > > > >
> > >> > > >> >> > > > >
> > >> > > >> >> > > > >
> > >> > > >> >> > > > > --
> > >> > > >> >> > > > > Andrey Chernyshev
> > >> > > >> >> > > > > 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
> > >> > > >> >> > > >
> > >> > > >> >> > > >
> > >> > > >> >> > >
> > >> > > >> >> > >
> > >> > > >> >> > > --
> > >> > > >> >> > > Andrey Chernyshev
> > >> > > >> >> > > 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
> > >> > > >>
> > >> > > >>
> > >> > > >
> > >> > > >
> > >> ---------------------------------------------------------------------
> > >> > > > 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
> > >
> >
> >
> > ---------------------------------------------------------------------
> > 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
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
Posted by Evgueni Brevnov <ev...@gmail.com>.
It works because the test depends on helper threads that are running
in the VM simultaneously with the test. Depending on start up time of
system threads test passes or fails.
Evgueni
On 10/9/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> at least cunit tests instabilities should not prevent the patch
> submission. It can take significant time to make them pass on
> different configurations.....
>
> Evgueni
>
> On 10/9/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> > Geir, Salikh,
> >
> > cunit tests are very unstable...... that's why we have different
> > results on different platforms. It all tests problems. I already fixed
> > several places but it seems there is much more left. I believe we need
> > to revise them all. The main problem is that sleep(somthing) is used
> > to synchronize different threads. Sometimes there is no synchraniztion
> > at all. I propouse for switching it off until they get stable.
> > Can we do it?
> >
> > Evgueni
> >
> > On 10/9/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> > > Could you insert sleep_a_click(); just before line 59 right after
> > > hysem_create(&start, 0, 1):
> > >
> > > Does it help?
> > >
> > > On 10/9/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> > > > [echo] ## Executing C unit test: test_ti_instrum
> > > > [exec] Result: 1
> > > > [echo] INFO: TEST test_jthread_get_all_threads start
> > > > [echo] ERROR: Assertion '(thread_count)==(i +
> > > > initial_thread_count)' failed at /home/geir/dev/apache/harmony/
> > > > enhanced/trunk/working_vm/vm/tes
> > > > ts/unit/thread/test_ti_instrum.c:94
> > > > [echo] Init1: initial_thread_count=1, initial_all_threads_count=1
> > > > [echo] Init3: initial_thread_count=1, initial_all_threads_count=1
> > > > [echo] Init3: thread_count=3, all_threads_count=3
> > > > [echo] INFO: TEST test_jthread_get_all_threads: FAILED
> > > > [echo] INFO: TEST test_jthread_get_thread_count start
> > > > [echo] Init1: initial_thread_count=3, initial_all_threads_count=3
> > > > [echo] INFO: TEST test_jthread_get_thread_count: PASSED
> > > > [echo] INFO: TEST test_jthread_get_blocked_count start
> > > > [echo] INFO: TEST test_jthread_get_blocked_count: PASSED
> > > > [echo] ## TEST FAILED
> > > >
> > > >
> > > > On Oct 9, 2006, at 12:35 AM, Evgueni Brevnov wrote:
> > > >
> > > > > I put debug printing into test_ti_instrum.c and attached it to JIRA.
> > > > > Could you run it on your machine and send me console output.
> > > > >
> > > > > Evgueni
> > > > >
> > > > > On 10/9/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> > > > >> I keep getting a failure when running the tests -
> > > > >>
> > > > >> test_jthread_get_all-threads failling the assertion at
> > > > >> test_ti_instrum.c:80
> > > > >>
> > > > >> geir
> > > > >>
> > > > >> On Oct 8, 2006, at 7:19 AM, Evgueni Brevnov wrote:
> > > > >>
> > > > >> > While running cunit on Linux it turned out one test case fails some
> > > > >> > time. The fix is in tests.final.2.patch.
> > > > >> >
> > > > >> > So the last versions to be committed:
> > > > >> > invocation_api.final.patch
> > > > >> > build.final.2.patch
> > > > >> > tests.final.2.patch
> > > > >> >
> > > > >> > Evgueni
> > > > >> >
> > > > >> >
> > > > >> > On 10/8/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> > > > >> >> I mahaged to resolve the problem on Linux.... will update
> > > > >> >> build.final.patch with build.final.2.patch in a while
> > > > >> >>
> > > > >> >> On 10/8/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> > > > >> >> > Hi,
> > > > >> >> >
> > > > >> >> > Oh! Ooh! I did that..... I passed cunit, somke, kernel tests on
> > > > >> >> > Windows and smoke, kernel tests on Linux. Unfortunately I
> > > > >> failed to
> > > > >> >> > link cunit tests on Linux so far. So I disabled cunit on Linux
> > > > >> >> until
> > > > >> >> > the problem is solved. I believe it is acceptable as short term
> > > > >> >> > solution. I found several problems in cunit tests. I will come
> > > > >> >> up with
> > > > >> >> > my findings later (not today).
> > > > >> >> >
> > > > >> >> > Use latest patches from HARMONY-1582. They are marked as final.
> > > > >> >> There
> > > > >> >> > are three patches. One for build module, one for cunit tests and
> > > > >> >> one
> > > > >> >> > for VM itself.
> > > > >> >> >
> > > > >> >> > Thanks
> > > > >> >> > Evgueni
> > > > >> >> >
> > > > >> >> >
> > > > >> >> > On 10/6/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> > > > >> >> > > Nooooooo! LOL
> > > > >> >> > >
> > > > >> >> > > I'm here waiting - This will unblock a whole bunch of
> > > > >> things :)
> > > > >> >> > >
> > > > >> >> > > Thanks for the effort
> > > > >> >> > >
> > > > >> >> > > Evgueni Brevnov wrote:
> > > > >> >> > > > Geir,
> > > > >> >> > > >
> > > > >> >> > > > That's terrible. We have power outage....servers are down. I
> > > > >> >> can't
> > > > >> >> > > > send the patches now.... will do it tomorrow
> > > > >> >> > > >
> > > > >> >> > > > Evgueni
> > > > >> >> > > > On 10/5/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> > > > >> >> > > >> woo hoo! here we go...
> > > > >> >> > > >>
> > > > >> >> > > >>
> > > > >> >> > > >> Andrey Chernyshev wrote:
> > > > >> >> > > >> > Hi Evgueni,
> > > > >> >> > > >> >
> > > > >> >> > > >> > On 10/4/06, Evgueni Brevnov <ev...@gmail.com>
> > > > >> >> wrote:
> > > > >> >> > > >> >> Hi All,
> > > > >> >> > > >> >>
> > > > >> >> > > >> >> I have attached updated patch to the JIRA. It should
> > > > >> >> resolve remain
> > > > >> >> > > >> >> concerns. Andrey, could you give a green light now?
> > > > >> >> > > >> >
> > > > >> >> > > >> > Thanks for updating the patch! I agree it it can be
> > > > >> >> committed, at
> > > > >> >> > > >> > least signatures look good. 5 revisions seem like more
> > > > >> >> than enough :).
> > > > >> >> > > >> > Anyways, I think the remaining issues can be resolved
> > > > >> >> with additional
> > > > >> >> > > >> > patches. Thanks again for the good work and your
> > > > >> patience.
> > > > >> >> > > >> >
> > > > >> >> > > >> > Thanks,
> > > > >> >> > > >> > Andrey.
> > > > >> >> > > >> >
> > > > >> >> > > >> >>
> > > > >> >> > > >> >> Thanks
> > > > >> >> > > >> >> Evgueni
> > > > >> >> > > >> >>
> > > > >> >> > > >> >> On 10/4/06, Evgueni Brevnov <ev...@gmail.com>
> > > > >> >> wrote:
> > > > >> >> > > >> >> > Andrey,
> > > > >> >> > > >> >> >
> > > > >> >> > > >> >> > I see your points. I think both approaches have
> > > > >> >> advantages and
> > > > >> >> > > >> >> > disadvantages. I think it is quite hard to say which
> > > > >> >> approach is
> > > > >> >> > > >> >> > better until we play with one VM only. I still feel
> > > > >> >> like introducing
> > > > >> >> > > >> >> > one more dependence is better than spreading code
> > > > >> >> which deals with
> > > > >> >> > > >> >> > attachment among VM and TM. We really get stuck. OK,
> > > > >> >> just because I
> > > > >> >> > > >> >> > want to move forward I will do required changes to
> > > > >> remove
> > > > >> >> > > >> >> > vm_create_jthread from TM. I believe that will resolve
> > > > >> >> all our
> > > > >> >> > > >> >> > disagreements and the patch will be applied soon.
> > > > >> >> > > >> >> >
> > > > >> >> > > >> >> >
> > > > >> >> > > >> >> > Thanks
> > > > >> >> > > >> >> > Evgueni.
> > > > >> >> > > >> >> >
> > > > >> >> > > >> >> > On 10/4/06, Andrey Chernyshev
> > > > >> >> <a....@gmail.com> wrote:
> > > > >> >> > > >> >> > > On 10/3/06, Evgueni Brevnov
> > > > >> >> <ev...@gmail.com> wrote:
> > > > >> >> > > >> >> > > > On 10/3/06, Andrey Chernyshev
> > > > >> >> <a....@gmail.com> wrote:
> > > > >> >> > > >> >> > > > > On 10/2/06, Evgueni Brevnov
> > > > >> >> <ev...@gmail.com> wrote:
> > > > >> >> > > >> >> > > > > > Andrey,
> > > > >> >> > > >> >> > > > > >
> > > > >> >> > > >> >> > > > > > Just to be clear.... I agree with you it is
> > > > >> more
> > > > >> >> > > >> convenient if
> > > > >> >> > > >> >> > > > > > jthread_create takes JNIEnv instead of
> > > > >> JavaVM. It
> > > > >> >> > > >> reflects that
> > > > >> >> > > >> >> > > > > > current thread has been attached already. Do
> > > > >> >> you think it
> > > > >> >> > > >> >> makes sense
> > > > >> >> > > >> >> > > > > > to get rid of JNIEnv and use
> > > > >> >> jthread_get_JNI_env in that
> > > > >> >> > > >> case?
> > > > >> >> > > >> >> > > > >
> > > > >> >> > > >> >> > > > > The jthread_* layer is designed like if it were
> > > > >> >> a regular JNI
> > > > >> >> > > >> >> > > > > application which is meant to be called from the
> > > > >> >> Java code,
> > > > >> >> > > >> hence
> > > > >> >> > > >> >> > > > > every function on that layer receives JNIenv. We
> > > > >> >> can probably
> > > > >> >> > > >> >> get rid
> > > > >> >> > > >> >> > > > > of the JNEnv parameter for jthread_* functions,
> > > > >> >> assuming that
> > > > >> >> > > >> >> TM can
> > > > >> >> > > >> >> > > > > always extract JNIenv for the current thread
> > > > >> with
> > > > >> >> > > >> >> > > > > jthread_get_JNI_env().
> > > > >> >> > > >> >> > > > > My only concern would be the performance - once
> > > > >> >> the JNIenv is
> > > > >> >> > > >> >> already
> > > > >> >> > > >> >> > > > > known for the native part of the kernel classes
> > > > >> >> impl, it
> > > > >> >> > > >> must be
> > > > >> >> > > >> >> > > > > cheaper to pass JNIEnv to TM as an extra
> > > > >> >> parameter rather than
> > > > >> >> > > >> >> extract
> > > > >> >> > > >> >> > > > > it from the TLS again.
> > > > >> >> > > >> >> > > > > Other than that, I see no strong advantages in
> > > > >> >> keeping JNIEnv
> > > > >> >> > > >> >> parameter.
> > > > >> >> > > >> >> > > > >
> > > > >> >> > > >> >> > > > >
> > > > >> >> > > >> >> > > > > > Regarding jthread_attach. I still didn't get
> > > > >> >> your point....
> > > > >> >> > > >> >> Clarify it
> > > > >> >> > > >> >> > > > > > please if you think jhread_attach should be
> > > > >> >> modified.
> > > > >> >> > > >> >> > > > >
> > > > >> >> > > >> >> > > > > Sorry for being not clear: I think for
> > > > >> >> jthread_attach, we have
> > > > >> >> > > >> >> two options:
> > > > >> >> > > >> >> > > > > 1) Make JNIEnv input parameter - it must be new
> > > > >> >> JNIEnv that VM
> > > > >> >> > > >> >> > > > > pre-allocates for the new Java thread.
> > > > >> >> jthread_attach
> > > > >> >> > > >> would just
> > > > >> >> > > >> >> > > > > associate it with the current thread.
> > > > >> >> > > >> >> > > > >
> > > > >> >> > > >> >> > > > > 2) Obtain JNIEnv via vm_attach() callback. In
> > > > >> >> this case, if
> > > > >> >> > > >> >> > > > > vm_attach() callback implementation needs to
> > > > >> >> know for which
> > > > >> >> > > >> >> JavaVM new
> > > > >> >> > > >> >> > > > > JNIenv has to be allocated, then we'll need to
> > > > >> >> add JavaVM as
> > > > >> >> > > >> >> input
> > > > >> >> > > >> >> > > > > parameter for jthread_attach().
> > > > >> >> > > >> >> > > > > I think both options should be fine, (1) would
> > > > >> >> probably
> > > > >> >> > > >> keep TM
> > > > >> >> > > >> >> > > > > interface a bit lighter, though (2) may look
> > > > >> >> more closer to
> > > > >> >> > > >> >> the JNI
> > > > >> >> > > >> >> > > > > invocation API idea.
> > > > >> >> > > >> >> > > > > So I think adding JavaVM specifically for
> > > > >> >> jthread_attach
> > > > >> >> > > >> may make
> > > > >> >> > > >> >> > > > > sense given the explanation you provided
> > > > >> earlier.
> > > > >> >> > > >> >> > > > >
> > > > >> >> > > >> >> > > > > The concern I would have regarding the proposed
> > > > >> >> jthread_attach
> > > > >> >> > > >> >> > > > > implementation is a call to vm_create_jthread()
> > > > >> >> - this call
> > > > >> >> > > >> >> introduces
> > > > >> >> > > >> >> > > > > an extra dependency of TM on vmcore that I'd
> > > > >> >> prefer to be
> > > > >> >> > > >> >> avoided. In
> > > > >> >> > > >> >> > > > > the original version, jthread_attach() was
> > > > >> >> taking jthread
> > > > >> >> > > >> >> argument of
> > > > >> >> > > >> >> > > > > the already prepared j.l.Thread.
> > > > >> >> > > >> >> > > >
> > > > >> >> > > >> >> > > > I understand your concern. Unfortunately I don't
> > > > >> >> see what we
> > > > >> >> > > >> can do
> > > > >> >> > > >> >> > > > here. Let me explain. In the beginning you have an
> > > > >> >> unattached
> > > > >> >> > > >> >> native
> > > > >> >> > > >> >> > > > thread. To be able to call java code (which is
> > > > >> >> required for
> > > > >> >> > > >> >> > > > constructing j.l.Thread instance) the thread
> > > > >> >> should be attached
> > > > >> >> > > >> >> first.
> > > > >> >> > > >> >> > > > To be specific it should be attached to VM by
> > > > >> >> calling vm_attach
> > > > >> >> > > >> >> which
> > > > >> >> > > >> >> > > > will return a valid JNIEnv It is valid to use JNI
> > > > >> >> from that
> > > > >> >> > > >> moment.
> > > > >> >> > > >> >> > > > Obtained JNIEnv can be used to execute java code
> > > > >> >> and create
> > > > >> >> > > >> >> j.l.Thread
> > > > >> >> > > >> >> > > > instance. Since we do vm_attach in jthread_attach
> > > > >> >> we need to do
> > > > >> >> > > >> >> > > > vm_create_jthread inside jthread_atach as well.
> > > > >> >> > > >> >> > > > Of course it can be an alternative to do vm_attach
> > > > >> >> and
> > > > >> >> > > >> >> > > > vm_create_jthread outside of TM right before
> > > > >> >> jthread_attach.
> > > > >> >> > > >> >> Sure it
> > > > >> >> > > >> >> > > > will reduce one dependence between VM and TM. But
> > > > >> >> it seems like
> > > > >> >> > > >> >> > > > artificial action for me just because of
> > > > >> >> dependency....
> > > > >> >> > > >> >> > >
> > > > >> >> > > >> >> > > Why do you think it is artificial? I would rather
> > > > >> >> prefer not to
> > > > >> >> > > >> throw
> > > > >> >> > > >> >> > > vm_attach event from the jthread_attach() call at
> > > > >> >> all than to add
> > > > >> >> > > >> >> > > extra dependency. The idea of jthread layer is a
> > > > >> >> Java face to
> > > > >> >> > > >> >> > > hythread, it is meant to know either a little or
> > > > >> >> nothing about the
> > > > >> >> > > >> >> > > rest of VM. It may be logical to throw vm_attach
> > > > >> >> call from the
> > > > >> >> > > >> newly
> > > > >> >> > > >> >> > > created thread, because there is no other way to let
> > > > >> >> know VM
> > > > >> >> > > >> the new
> > > > >> >> > > >> >> > > thread is created. VM attach is a different case -
> > > > >> >> VM already
> > > > >> >> > > >> knows
> > > > >> >> > > >> >> > > about new Java thread at the time of the
> > > > >> >> AttachCurrentThread call.
> > > > >> >> > > >> >> > >
> > > > >> >> > > >> >> > > >
> > > > >> >> > > >> >> > > > > Do you think it makes sense to replace a single
> > > > >> >> jthread
> > > > >> >> > > >> >> parameter with
> > > > >> >> > > >> >> > > > > a variety of stuff (like thread group, name)? It
> > > > >> >> seems the
> > > > >> >> > > >> only
> > > > >> >> > > >> >> > > > > purpose of at these args is to be passed back to
> > > > >> >> VM for
> > > > >> >> > > >> >> > > > > vm_jthread_create(). I would suggest to change
> > > > >> >> this and try
> > > > >> >> > > >> doing
> > > > >> >> > > >> >> > > > > either of:
> > > > >> >> > > >> >> > > > > 1) Make signature of jthread_attach with 3 args,
> > > > >> >> JavaVM,
> > > > >> >> > > >> >> jthread and the daemon.
> > > > >> >> > > >> >> > > > Why do you want to pass daemon to TM but thread's
> > > > >> >> name and
> > > > >> >> > > >> >> group. Just
> > > > >> >> > > >> >> > > > because current TM doesn't need such information?
> > > > >> >> What if it is
> > > > >> >> > > >> >> > > > required to get thread name later? Say by
> > > > >> introducing
> > > > >> >> > > >> >> > >
> > > > >> >> > > >> >> > > I imagine you need a daemon attribute since the TM
> > > > >> >> is still
> > > > >> >> > > >> managing
> > > > >> >> > > >> >> > > the thread daemonality. TM is not managing thread
> > > > >> >> name and group -
> > > > >> >> > > >> >> > > they are all kept on the Java level, hence passing
> > > > >> >> them may be
> > > > >> >> > > >> >> > > excessive.
> > > > >> >> > > >> >> > >
> > > > >> >> > > >> >> > > > jthread_get_name... What will you do in that case?
> > > > >> >> Let me
> > > > >> >> > > >> guess you
> > > > >> >> > > >> >> > > > will call j.l.Thread.getName. Right. Ok! In that
> > > > >> >> case I see no
> > > > >> >> > > >> >> > > > problems to call j.l.Thread.isDaemon. Do you
> > > > >> >> agree? So it
> > > > >> >> > > >> doesn't
> > > > >> >> > > >> >> > >
> > > > >> >> > > >> >> > > As I suggested earlier, the best way to handle
> > > > >> >> daemonality would
> > > > >> >> > > >> >> > > probably be in pure Java - in j.l.Thread (or
> > > > >> >> > > >> j.l.VMThreadManager) or
> > > > >> >> > > >> >> > > whatever. You already lifted it up to the jthread
> > > > >> >> level, but
> > > > >> >> > > >> what if
> > > > >> >> > > >> >> > > we can go a little bit higher...
> > > > >> >> > > >> >> > >
> > > > >> >> > > >> >> > > > seems to be a good design to pass only part of the
> > > > >> >> > > >> information to
> > > > >> >> > > >> >> > > > jthread_atach. Lets look at the signature of
> > > > >> >> > > >> >> AttachCurrentThread. It
> > > > >> >> > > >> >> > > > takes exactly these three parameters (daemon,
> > > > >> >> name, group)
> > > > >> >> > > >> >> passed as a
> > > > >> >> > > >> >> > > > structure. I was thinking about having exactly the
> > > > >> >> same
> > > > >> >> > > >> >> structure as
> > > > >> >> > > >> >> > > > third parameter of jthread_attach but it occured
> > > > >> >> to be more
> > > > >> >> > > >> >> convinient
> > > > >> >> > > >> >> > > > to pass them seperatly. Although I don't see
> > > > >> >> strong reasons
> > > > >> >> > > >> against
> > > > >> >> > > >> >> > > > having a structure a third parameter.
> > > > >> >> > > >> >> > >
> > > > >> >> > > >> >> > > I see. Acually, I would love to keep the
> > > > >> >> jthread_attach func-ty at
> > > > >> >> > > >> >> the
> > > > >> >> > > >> >> > > minimum level which will be needed to handle the
> > > > >> >> only data that TM
> > > > >> >> > > >> >> > > should be aware of. We need a formal boundary
> > > > >> >> between jthread
> > > > >> >> > > >> layer
> > > > >> >> > > >> >> > > and vmcore (otherwise jthread won't have a much of
> > > > >> >> sense, one may
> > > > >> >> > > >> >> > > consider it just as a convenience set of functions
> > > > >> >> in vmcore which
> > > > >> >> > > >> >> are
> > > > >> >> > > >> >> > > doing something with threading).
> > > > >> >> > > >> >> > >
> > > > >> >> > > >> >> > > >
> > > > >> >> > > >> >> > > > > 2) Move the implementation of vm_create_jtrhead
> > > > >> >> () to
> > > > >> >> > > >> >> > > > > thread_java_basic.c - could it be written in
> > > > >> >> pure JNI without
> > > > >> >> > > >> >> using
> > > > >> >> > > >> >> > > > > internal VM API like class_alloc_new_object()?
> > > > >> >> > > >> >> > > >
> > > > >> >> > > >> >> > > > Yes, this can be done but it doesn't fix the
> > > > >> >> problem. You still
> > > > >> >> > > >> >> need
> > > > >> >> > > >> >> > > > to know about internal constructor of j.l.Thread
> > > > >> >> > > >> >> > >
> > > > >> >> > > >> >> > > That's bad. Given what you said, now it seems that
> > > > >> >> the most
> > > > >> >> > > >> >> preferable
> > > > >> >> > > >> >> > > sequence for AttachCurrentThread impl still would be
> > > > >> >> like:
> > > > >> >> > > >> >> > > JNIEnv = vm_attach();
> > > > >> >> > > >> >> > > jthread = create_jthread(JNIenv)
> > > > >> >> > > >> >> > > jthread_attach(JNIEnv, jthread) // stores JNIEnv and
> > > > >> >> Hythread into
> > > > >> >> > > >> >> > > TLS, doesn't call vm_attach any longer.
> > > > >> >> > > >> >> > > - this is almost what we had from the beginning...
> > > > >> >> > > >> >> > >
> > > > >> >> > > >> >> > > Thanks,
> > > > >> >> > > >> >> > > Andrey.
> > > > >> >> > > >> >> > >
> > > > >> >> > > >> >> > > >
> > > > >> >> > > >> >> > > >
> > > > >> >> > > >> >> > > > Thanks
> > > > >> >> > > >> >> > > > Evgueni
> > > > >> >> > > >> >> > > > >
> > > > >> >> > > >> >> > > > >
> > > > >> >> > > >> >> > > > > Thanks,
> > > > >> >> > > >> >> > > > > Andrey.
> > > > >> >> > > >> >> > > > >
> > > > >> >> > > >> >> > > > > >
> > > > >> >> > > >> >> > > > > > Thank you
> > > > >> >> > > >> >> > > > > > Evgueni
> > > > >> >> > > >> >> > > > > >
> > > > >> >> > > >> >> > > > > > On 10/2/06, Evgueni Brevnov
> > > > >> >> <ev...@gmail.com>
> > > > >> >> > > >> wrote:
> > > > >> >> > > >> >> > > > > > > On 9/29/06, Andrey Chernyshev
> > > > >> >> <a....@gmail.com>
> > > > >> >> > > >> >> wrote:
> > > > >> >> > > >> >> > > > > > > > On 9/29/06, Evgueni Brevnov
> > > > >> >> <ev...@gmail.com>
> > > > >> >> > > >> >> wrote:
> > > > >> >> > > >> >> > > > > > > > > Artem,
> > > > >> >> > > >> >> > > > > > > > >
> > > > >> >> > > >> >> > > > > > > > > Thank you for your feedback.... find my
> > > > >> >> inlined.....
> > > > >> >> > > >> >> > > > > > > > >
> > > > >> >> > > >> >> > > > > > > > > On 9/29/06, Artem Aliev
> > > > >> >> <ar...@gmail.com> wrote:
> > > > >> >> > > >> >> > > > > > > > > > Evgueni,
> > > > >> >> > > >> >> > > > > > > > > >
> > > > >> >> > > >> >> > > > > > > > > > I got most of your changes, but still
> > > > >> >> disagree
> > > > >> >> > > >> with all
> > > > >> >> > > >> >> > > > > > > > > > hythread/jthread interface changes.
> > > > >> >> Could leave
> > > > >> >> > > >> >> interface unchanged.
> > > > >> >> > > >> >> > > > > > > > > > See following possible solutions, that
> > > > >> >> could solve
> > > > >> >> > > >> >> the same problems
> > > > >> >> > > >> >> > > > > > > > > > without interface changes.
> > > > >> >> > > >> >> > > > > > > > > >
> > > > >> >> > > >> >> > > > > > > > > >
> > > > >> >> > > >> >> > > > > > > > > > 1) daemon attribute is a java
> > > > >> >> specific. (Andrey
> > > > >> >> > > >> >> mentioned this already).
> > > > >> >> > > >> >> > > > > > > > > > Could you please move it back. to
> > > > >> >> the jthread
> > > > >> >> > > >> >> layer. It is better
> > > > >> >> > > >> >> > > > > > > > > > to rename
> > > > >> >> > > >> >> > > > > > > > > >
> > > > >> >> hythread_wait_for_all_nondaemon_threads() to
> > > > >> >> > > >> >> > > > > > > > > >
> > > > >> jthread_wait_for_all_nondaemon_threads().
> > > > >> >> > > >> >> > > > > > > > > Ok, I see no problems to move "daemon"
> > > > >> >> to java layer.
> > > > >> >> > > >> >> In that case:
> > > > >> >> > > >> >> > > > > > > > > 1) I will move
> > > > >> >> > > >> >> hythread_wait_for_all_nondaemon_threads() from
> > > > >> >> > > >> >> > > > > > > > > thread_init.c to one which implements
> > > > >> >> java layer.
> > > > >> >> > > >> >> > > > > > > > > 2) I will move daemon field from
> > > > >> >> HyThread structure.
> > > > >> >> > > >> >> > > > > > > > >
> > > > >> >> > > >> >> > > > > > > > > Agree?
> > > > >> >> > > >> >> > > > > > > >
> > > > >> >> > > >> >> > > > > > > > Sounds good to me.
> > > > >> >> > > >> >> > > > > > >
> > > > >> >> > > >> >> > > > > > > OK, will do that.
> > > > >> >> > > >> >> > > > > > >
> > > > >> >> > > >> >> > > > > > > >
> > > > >> >> > > >> >> > > > > > > >
> > > > >> >> > > >> >> > > > > > > > >
> > > > >> >> > > >> >> > > > > > > > > >
> > > > >> >> > > >> >> > > > > > > > > > 2) JavaVM could be retrieved from
> > > > >> >> JNIEnv by
> > > > >> >> > > >> >> jni_get_java_vm(). So
> > > > >> >> > > >> >> > > > > > > > > > let the jthread_create() and others to
> > > > >> >> use JNIEnv
> > > > >> >> > > >> >> (that is passed from
> > > > >> >> > > >> >> > > > > > > > > > java native method).
> > > > >> >> > > >> >> > > > > > > > > > The vm_attach could get old JNI env
> > > > >> >> and create new
> > > > >> >> > > >> >> one for the new thread.
> > > > >> >> > > >> >> > > > > > > > > > The first JNIEnv is created in
> > > > >> >> CreateVM call and
> > > > >> >> > > >> >> could be passed to
> > > > >> >> > > >> >> > > > > > > > > > the first thread at startup.
> > > > >> >> > > >> >> > > > > > > > > No, no, no. I completely disagree with
> > > > >> >> that!!! Why do
> > > > >> >> > > >> >> you like JNIEnv
> > > > >> >> > > >> >> > > > > > > > > but JavaVM. Why do you think that
> > > > >> >> passing JavaVM
> > > > >> >> > > >> >> instead of JNIEnv
> > > > >> >> > > >> >> > > > > > > > > makes TM less modular? I don't see any
> > > > >> >> difference
> > > > >> >> > > >> >> here.... It seems
> > > > >> >> > > >> >> > > > > > > > > for me like a big big hack to grab
> > > > >> >> JNIEnv from another
> > > > >> >> > > >> >> thread and pass
> > > > >> >> > > >> >> > > > > > > > > it to jthread_attach to perform
> > > > >> >> operations in the
> > > > >> >> > > >> >> current thread.
> > > > >> >> > > >> >> > > > > > > >
> > > > >> >> > > >> >> > > > > > > > TM needs to know JNIEnv, mainly for
> > > > >> >> managing the
> > > > >> >> > > >> >> references to
> > > > >> >> > > >> >> > > > > > > > objects, throwing exceptions and calling
> > > > >> >> run() method of
> > > > >> >> > > >> >> a new thread.
> > > > >> >> > > >> >> > > > > > > > JNI spec proposes that JNIEnv is valid
> > > > >> >> within the given
> > > > >> >> > > >> >> thread, this
> > > > >> >> > > >> >> > > > > > > > is why TM holds the JNIEnv pointer at the
> > > > >> >> moment. This
> > > > >> >> > > >> >> is why TM likes
> > > > >> >> > > >> >> > > > > > > > the JNIEnv.
> > > > >> >> > > >> >> > > > > > > >
> > > > >> >> > > >> >> > > > > > > > Having the JNIEnv, one is able to get
> > > > >> >> JavaVM but not
> > > > >> >> > > >> >> vise versa. This
> > > > >> >> > > >> >> > > > > > > > is why TM doesn't like the JavaVM :)
> > > > >> >> > > >> >> > > > > > > I see your point. Only one note this is true
> > > > >> >> for already
> > > > >> >> > > >> >> attached threads...
> > > > >> >> > > >> >> > > > > > >
> > > > >> >> > > >> >> > > > > > > >
> > > > >> >> > > >> >> > > > > > > > I agree with you that there is a design
> > > > >> >> flaw that the
> > > > >> >> > > >> >> JNIEnv is copied
> > > > >> >> > > >> >> > > > > > > > from the parent thread to a child thread
> > > > >> >> during thread
> > > > >> >> > > >> >> creation. I
> > > > >> >> > > >> >> > > > > > > > think it could be resolved via vm_attach()
> > > > >> >> hook - with
> > > > >> >> > > >> >> this event, VM
> > > > >> >> > > >> >> > > > > > > > might tell the TM what the JNIEnv pointer
> > > > >> >> for new thread
> > > > >> >> > > >> >> should be. I
> > > > >> >> > > >> >> > > > > > > > think you did that by extending the
> > > > >> >> vm_attach() call
> > > > >> >> > > >> >> with the JNIEnv**
> > > > >> >> > > >> >> > > > > > > > argument.
> > > > >> >> > > >> >> > > > > > > >
> > > > >> >> > > >> >> > > > > > > > What is not completely clear is, why do
> > > > >> >> you have to pass
> > > > >> >> > > >> >> the JavaVM
> > > > >> >> > > >> >> > > > > > > > forth and back, once from VM to TM, and
> > > > >> >> then back from
> > > > >> >> > > >> >> TM to VM again?
> > > > >> >> > > >> >> > > > > > > >
> > > > >> >> > > >> >> > > > > > > > If you need to know in jthread_attach,
> > > > >> >> which particular
> > > > >> >> > > >> >> VM vm_attach()
> > > > >> >> > > >> >> > > > > > > > event is coming from, you could have
> > > > >> >> vm_attach like
> > > > >> >> > > >> >> > > > > > > > vm_attach(JNIEnv* currentThreadEnv,
> > > > >> JNIEnv**
> > > > >> >> > > >> >> newThreadEnv).
> > > > >> >> > > >> >> > > > > > > I'm a little bit confused.....Current thread
> > > > >> >> hasn't been
> > > > >> >> > > >> >> attached yet.
> > > > >> >> > > >> >> > > > > > > So there is no JNIEnv for it yet. How it can
> > > > >> >> be passed as
> > > > >> >> > > >> >> the first
> > > > >> >> > > >> >> > > > > > > parameter to vm_attach()?
> > > > >> >> > > >> >> > > > > > >
> > > > >> >> > > >> >> > > > > > > > Then you will be always able to get the
> > > > >> >> JavaVM from the
> > > > >> >> > > >> >> JNIEnv.
> > > > >> >> > > >> >> > > > > > > > The only difference is that you are
> > > > >> >> currently doing
> > > > >> >> > > >> >> JNIEnv->JavaVM
> > > > >> >> > > >> >> > > > > > > > conversion in the VMThreadManager, but why
> > > > >> >> can't you
> > > > >> >> > > >> >> just do this in
> > > > >> >> > > >> >> > > > > > > > vm_attach() without changing the interface
> > > > >> >> of the TM?
> > > > >> >> > > >> >> > > > > > > > So far JavaVM really looks like an extra
> > > > >> >> knowledge that
> > > > >> >> > > >> >> TM doesn't
> > > > >> >> > > >> >> > > > > > > > have to be aware of.
> > > > >> >> > > >> >> > > > > > > >
> > > > >> >> > > >> >> > > > > > > > > Moreover there is no JNIEnv when main
> > > > >> >> thread attaches
> > > > >> >> > > >> >> to VM. So we
> > > > >> >> > > >> >> > > > > > > > > should either keep it as is or change
> > > > >> >> original design
> > > > >> >> > > >> >> of TM and attach
> > > > >> >> > > >> >> > > > > > > > > thread to VM before attaching it to TM.
> > > > >> >> In that case
> > > > >> >> > > >> >> we will have
> > > > >> >> > > >> >> > > > > > > > > valid JNIEnv which can be passed to
> > > > >> >> jthread_atatch. We
> > > > >> >> > > >> >> need to think
> > > > >> >> > > >> >> > > > > > > > > over it twice before changing
> > > > >> something....
> > > > >> >> > > >> >> > > > > > > >
> > > > >> >> > > >> >> > > > > > > > Right. For jthread_attach, JNIenv needs to
> > > > >> >> be changed
> > > > >> >> > > >> >> from being input
> > > > >> >> > > >> >> > > > > > > > parameter to being the output parameter.
> > > > >> >> The way how
> > > > >> >> > > >> >> JNIenv is
> > > > >> >> > > >> >> > > > > > > > obtained by TM should be vm_attach()
> > > > >> event.
> > > > >> >> > > >> >> > > > > > > OK, JNIEnv is output parameter. And it
> > > > >> >> obtained by
> > > > >> >> > > >> >> vm_attach(). This
> > > > >> >> > > >> >> > > > > > > is exactly like I do in the patch. What I
> > > > >> >> don't understand
> > > > >> >> > > >> >> is how
> > > > >> >> > > >> >> > > > > > > jthread_attach knows to which VM the thread
> > > > >> >> should be
> > > > >> >> > > >> >> attached? Do you
> > > > >> >> > > >> >> > > > > > > suggest calling vm_attach first to create
> > > > >> >> JNIEnv it pass
> > > > >> >> > > >> >> it to
> > > > >> >> > > >> >> > > > > > > jthread_attach?
> > > > >> >> > > >> >> > > > > > >
> > > > >> >> > > >> >> > > > > > > >
> > > > >> >> > > >> >> > > > > > > > >
> > > > >> >> > > >> >> > > > > > > > >
> > > > >> >> > > >> >> > > > > > > > >
> > > > >> >> > > >> >> > > > > > > > > >
> > > > >> >> > > >> >> > > > > > > > > >
> > > > >> >> > > >> >> > > > > > > > > > 4) Original classlib hythread do
> > > > >> not use
> > > > >> >> > > >> >> hythread_library_t in arguments,
> > > > >> >> > > >> >> > > > > > > > > > It uses following code:
> > > > >> >> > > >> >> > > > > > > > > >
> > > > >> >> > > >> >> > > > > > > > > > hythread_library_t lib = GLOBAL_DATA
> > > > >> >> > > >> >> (default_library);
> > > > >> >> > > >> >> > > > > > > > > > or
> > > > >> >> > > >> >> > > > > > > > > > hythread_library_t library = thread-
> > > > >> >> >library;
> > > > >> >> > > >> >> > > > > > > > > >
> > > > >> >> > > >> >> > > > > > > > > > So could you please use the same
> > > > >> >> mechanism and
> > > > >> >> > > >> >> remove hythread_*_ex >functions.
> > > > >> >> > > >> >> > > > > > > > > Let's see if classlib's hythread needs
> > > > >> >> changing first.
> > > > >> >> > > >> >> It seems for me
> > > > >> >> > > >> >> > > > > > > > > such code prevents us from having
> > > > >> multi VM.
> > > > >> >> > > >> >> > > > > > > > >
> > > > >> >> > > >> >> > > > > > > > > >
> > > > >> >> > > >> >> > > > > > > > > > 5. You introduce more then one jni
> > > > >> >> env, but still
> > > > >> >> > > >> >> use global variable for it.
> > > > >> >> > > >> >> > > > > > > > > > So all changes like following:
> > > > >> >> > > >> >> > > > > > > > > > - JNIEnv *jenv = (JNIEnv*)
> > > > >> >> jni_native_intf;
> > > > >> >> > > >> >> > > > > > > > > > + JNIEnv *jenv = jni_native_intf;
> > > > >> >> > > >> >> > > > > > > > > >
> > > > >> >> > > >> >> > > > > > > > > > should be like:
> > > > >> >> > > >> >> > > > > > > > > > - JNIEnv *jenv = (JNIEnv*)
> > > > >> >> jni_native_intf;
> > > > >> >> > > >> >> > > > > > > > > > + JNIEnv *jenv = get_jni_env
> > > > >> >> (jthread_self());
> > > > >> >> > > >> >> > > > > > > > >
> > > > >> >> > > >> >> > > > > > > > > Ok, I see. I agree that global
> > > > >> >> jni_native_intf should
> > > > >> >> > > >> >> not be used.
> > > > >> >> > > >> >> > > > > > > > > There was simple reason why I altered
> > > > >> >> such lines.
> > > > >> >> > > >> >> Because I changed
> > > > >> >> > > >> >> > > > > > > > > the type of jni_native_intf and no
> > > > >> >> casting operator
> > > > >> >> > > >> >> is needed now. To
> > > > >> >> > > >> >> > > > > > > > > be honest I think get_jni_env
> > > > >> >> (jthread_self()) can be
> > > > >> >> > > >> >> good as temporary
> > > > >> >> > > >> >> > > > > > > > > solution only. Lets wait for design of
> > > > >> >> multi VM and
> > > > >> >> > > >> >> fix it according
> > > > >> >> > > >> >> > > > > > > > > to it.
> > > > >> >> > > >> >> > > > > > > >
> > > > >> >> > > >> >> > > > > > > > While we are in JNI code, we always have
> > > > >> >> the JNIenv (at
> > > > >> >> > > >> >> least
> > > > >> >> > > >> >> > > > > > > > initially it comes from Java code). If we
> > > > >> >> consider VM
> > > > >> >> > > >> >> code as if it
> > > > >> >> > > >> >> > > > > > > > was a JNI application, then it seems like
> > > > >> >> we should be
> > > > >> >> > > >> >> just passing
> > > > >> >> > > >> >> > > > > > > > JNIEnv as a parameter to all functions in
> > > > >> >> VM. Or, we can
> > > > >> >> > > >> >> be taking it
> > > > >> >> > > >> >> > > > > > > > from TLS (via jthread_self()), depending
> > > > >> >> on which way is
> > > > >> >> > > >> >> faster...
> > > > >> >> > > >> >> > > > > > > Agree.
> > > > >> >> > > >> >> > > > > > >
> > > > >> >> > > >> >> > > > > > > >
> > > > >> >> > > >> >> > > > > > > > >
> > > > >> >> > > >> >> > > > > > > > > >
> > > > >> >> > > >> >> > > > > > > > > > 6). And small remarks:
> > > > >> >> > > >> >> > > > > > > > > > +jint vm_init1(JavaVM_Internal *
> > > > >> java_vm,
> > > > >> >> > > >> >> JavaVMInitArgs * vm_arguments);
> > > > >> >> > > >> >> > > > > > > > > > +jint vm_init2(JNIEnv_Internal *
> > > > >> >> jni_env);
> > > > >> >> > > >> >> > > > > > > > > > Could you make names more meaningful,
> > > > >> >> then 1,2,3...?
> > > > >> >> > > >> >> > > > > > > > > Ok, will do that.
> > > > >> >> > > >> >> > > > > > > > >
> > > > >> >> > > >> >> > > > > > > > > >
> > > > >> >> > > >> >> > > > > > > > > > class VM_thread {
> > > > >> >> > > >> >> > > > > > > > > > ...
> > > > >> >> > > >> >> > > > > > > > > > + JNIEnv_Internal * jni_env;
> > > > >> >> > > >> >> > > > > > > > > > The jthread already has the jni_env
> > > > >> >> pointer, you do
> > > > >> >> > > >> >> not need to
> > > > >> >> > > >> >> > > > > > > > > > duplicate it here.
> > > > >> >> > > >> >> > > > > > > > > > forexample by using
> > > > >> >> > > >> >> jthread_get_JNI_env(jthread_self());
> > > > >> >> > > >> >> > > > > > > > >
> > > > >> >> > > >> >> > > > > > > > > Yes I know. I don't see any problems
> > > > >> >> here. Some times
> > > > >> >> > > >> >> it is much more
> > > > >> >> > > >> >> > > > > > > > > convenient to get JNIEnv from VM_thread
> > > > >> >> structure (and
> > > > >> >> > > >> >> faster) instead
> > > > >> >> > > >> >> > > > > > > > > of doing jthread_get_JNI_env
> > > > >> (jthread_self
> > > > >> >> ()). So I
> > > > >> >> > > >> >> need strong
> > > > >> >> > > >> >> > > > > > > > > arguments for removing it. Again it
> > > > >> >> seems that should
> > > > >> >> > > >> >> be addressed in
> > > > >> >> > > >> >> > > > > > > > > design of multi VM. So lets forget about
> > > > >> >> it for a
> > > > >> >> > > >> >> while...
> > > > >> >> > > >> >> > > > > > > >
> > > > >> >> > > >> >> > > > > > > > I think that the data duplication would
> > > > >> >> always serve as
> > > > >> >> > > >> >> a potential
> > > > >> >> > > >> >> > > > > > > > source of errors - while updating one copy
> > > > >> >> of object,
> > > > >> >> > > >> >> you may forget
> > > > >> >> > > >> >> > > > > > > > to update the other, often resulting into
> > > > >> >> a strange
> > > > >> >> > > >> >> behavior of the
> > > > >> >> > > >> >> > > > > > > > whole application. Let's see what are the
> > > > >> >> specific
> > > > >> >> > > >> >> performance
> > > > >> >> > > >> >> > > > > > > > concerns that have to be addressed. To get
> > > > >> >> VM_thread
> > > > >> >> > > >> >> structure, you
> > > > >> >> > > >> >> > > > > > > > would eventually go to the TLS, just like
> > > > >> >> > > >> >> > > > > > > > jthread_get_JNI_env(jthread_self()
> > > > >> would do.
> > > > >> >> > > >> >> > > > > > > If there is already VM_thread structure for
> > > > >> >> some reasons
> > > > >> >> > > >> >> then there
> > > > >> >> > > >> >> > > > > > > will be no extra access to TLS. It is
> > > > >> >> definitely much
> > > > >> >> > > >> more in
> > > > >> >> > > >> >> > > > > > > jthread_get_JNI_env(jthread_self() than just
> > > > >> >> one TLS
> > > > >> >> > > >> >> access and one
> > > > >> >> > > >> >> > > > > > > dereferncing. I don't think it is a really
> > > > >> >> big problem
> > > > >> >> > > >> >> now. Do you
> > > > >> >> > > >> >> > > > > > > agree to look at this later. I guess
> > > > >> multi VM
> > > > >> >> > > >> >> implementation will
> > > > >> >> > > >> >> > > > > > > alter it in any case.
> > > > >> >> > > >> >> > > > > > >
> > > > >> >> > > >> >> > > > > > > Thanks
> > > > >> >> > > >> >> > > > > > > Evgueni
> > > > >> >> > > >> >> > > > > > >
> > > > >> >> > > >> >> > > > > > > >
> > > > >> >> > > >> >> > > > > > > > Thanks,
> > > > >> >> > > >> >> > > > > > > > Andrey.
> > > > >> >> > > >> >> > > > > > > >
> > > > >> >> > > >> >> > > > > > > > >
> > > > >> >> > > >> >> > > > > > > > > Evgueni
> > > > >> >> > > >> >> > > > > > > > > >
> > > > >> >> > > >> >> > > > > > > > > > Thanks
> > > > >> >> > > >> >> > > > > > > > > > Artem
> > > > >> >> > > >> >> > > > > > > > > >
> > > > >> >> > > >> >> > > > > > > > > > On 9/28/06, Evgueni Brevnov
> > > > >> >> > > >> >> <ev...@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.
> > > > >> >> > > >> >> > > > > > > > > > >
> > > > >> >> > > >> >> > > > > > > > > > > Thanks
> > > > >> >> > > >> >> > > > > > > > > > > Evgueni
> > > > >> >> > > >> >> > > > > > > > > > >
> > > > >> >> > > >> >> > > > > > > > > > > On 9/28/06, Geir Magnusson Jr.
> > > > >> >> <ge...@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
> > > > >> >> > > >> >> <we...@gmail.com> wrote:
> > > > >> >> > > >> >> > > > > > > > > > > > >> On 9/26/06, Evgueni Brevnov
> > > > >> >> > > >> >> <ev...@gmail.com> wrote:
> > > > >> >> > > >> >> > > > > > > > > > > > >> >
> > > > >> >> > > >> >> > > > > > > > > > > > >> > On 9/27/06, Andrey Chernyshev
> > > > >> >> > > >> >> <a....@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
> > > > >> >> > > >> >> > > > > > > > > > >
> > > > >> >> > > >> >> > > > > > > > > > >
> > > > >> >> > > >> >> > > > > > > > > >
> > > > >> >> > > >> >> > > > > > > > > >
> > > > >> >> > > >> >>
> > > > >> >>
> > > > >> ---------------------------------------------------------------------
> > > > >> >> > > >> >> > > > > > > > > > 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
> > > > >> >> > > >> >> > > > > > > > >
> > > > >> >> > > >> >> > > > > > > > >
> > > > >> >> > > >> >> > > > > > > >
> > > > >> >> > > >> >> > > > > > > >
> > > > >> >> > > >> >> > > > > > > > --
> > > > >> >> > > >> >> > > > > > > > Andrey Chernyshev
> > > > >> >> > > >> >> > > > > > > > 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
> > > > >> >> > > >> >> > > > > >
> > > > >> >> > > >> >> > > > > >
> > > > >> >> > > >> >> > > > >
> > > > >> >> > > >> >> > > > >
> > > > >> >> > > >> >> > > > > --
> > > > >> >> > > >> >> > > > > Andrey Chernyshev
> > > > >> >> > > >> >> > > > > 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
> > > > >> >> > > >> >> > > >
> > > > >> >> > > >> >> > > >
> > > > >> >> > > >> >> > >
> > > > >> >> > > >> >> > >
> > > > >> >> > > >> >> > > --
> > > > >> >> > > >> >> > > Andrey Chernyshev
> > > > >> >> > > >> >> > > 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
> > > > >> >> > > >>
> > > > >> >> > > >>
> > > > >> >> > > >
> > > > >> >> > > >
> > > > >> >>
> > > > >> ---------------------------------------------------------------------
> > > > >> >> > > > 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
> > > > >> >
> > > > >>
> > > > >>
> > > > >> ---------------------------------------------------------------------
> > > > >> 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
> > > >
> > > >
> > >
> >
>
---------------------------------------------------------------------
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
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Congratulations, all!
Alexey Varlamov wrote:
> Hurray! We did it at last! Congratulations :)
>
> 2006/10/9, Evgueni Brevnov <ev...@gmail.com>:
>> Ok, I go home. I have peace in my mind now :-)
>>
>> Thank you all
>> Evgueni
>>
>> On 10/9/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>> > ok - I just passed a smoke test, gc.PhantomReferenceQueueTest, that was
>> > failing. We should look at that and see why it's so flakey.
>> >
>> > If this works, I'm going to commit this thing so we can move forward.
>> >
>> > We should focus on stablizing the c-unit tests, btw...
>> >
>> > geir
>> >
>> >
>> > Geir Magnusson Jr. wrote:
>> > >
>> > >
>> > > Evgueni Brevnov wrote:
>> > >> Geir, Salikh,
>> > >>
>> > >> cunit tests are very unstable...... that's why we have different
>> > >> results on different platforms. It all tests problems. I already
>> fixed
>> > >> several places but it seems there is much more left. I believe we
>> need
>> > >> to revise them all. The main problem is that sleep(somthing) is used
>> > >> to synchronize different threads. Sometimes there is no
>> synchraniztion
>> > >> at all. I propouse for switching it off until they get stable.
>> > >> Can we do it?
>> > >
>> > > No. They all pass for me now, and I think that they are important as
>> > > they are better than nothing.
>> > >
>> > > I suspected that these were just timing issues - we should just
>> hunker
>> > > down and get them fixed ASAP. We're making progress
>> > >
>> > > geir
>> > >
>> > >>
>> > >> Evgueni
>> > >>
>> > >> On 10/9/06, Evgueni Brevnov <ev...@gmail.com> wrote:
>> > >>> Could you insert sleep_a_click(); just before line 59 right after
>> > >>> hysem_create(&start, 0, 1):
>> > >>>
>> > >>> Does it help?
>> > >>>
>> > >>> On 10/9/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>> > >>> > [echo] ## Executing C unit test: test_ti_instrum
>> > >>> > [exec] Result: 1
>> > >>> > [echo] INFO: TEST test_jthread_get_all_threads start
>> > >>> > [echo] ERROR: Assertion '(thread_count)==(i +
>> > >>> > initial_thread_count)' failed at /home/geir/dev/apache/harmony/
>> > >>> > enhanced/trunk/working_vm/vm/tes
>> > >>> > ts/unit/thread/test_ti_instrum.c:94
>> > >>> > [echo] Init1: initial_thread_count=1,
>> initial_all_threads_count=1
>> > >>> > [echo] Init3: initial_thread_count=1,
>> initial_all_threads_count=1
>> > >>> > [echo] Init3: thread_count=3, all_threads_count=3
>> > >>> > [echo] INFO: TEST test_jthread_get_all_threads: FAILED
>> > >>> > [echo] INFO: TEST test_jthread_get_thread_count start
>> > >>> > [echo] Init1: initial_thread_count=3,
>> initial_all_threads_count=3
>> > >>> > [echo] INFO: TEST test_jthread_get_thread_count: PASSED
>> > >>> > [echo] INFO: TEST test_jthread_get_blocked_count start
>> > >>> > [echo] INFO: TEST test_jthread_get_blocked_count: PASSED
>> > >>> > [echo] ## TEST FAILED
>> > >>> >
>> > >>> >
>> > >>> > On Oct 9, 2006, at 12:35 AM, Evgueni Brevnov wrote:
>> > >>> >
>> > >>> > > I put debug printing into test_ti_instrum.c and attached it
>> to JIRA.
>> > >>> > > Could you run it on your machine and send me console output.
>> > >>> > >
>> > >>> > > Evgueni
>> > >>> > >
>> > >>> > > On 10/9/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>> > >>> > >> I keep getting a failure when running the tests -
>> > >>> > >>
>> > >>> > >> test_jthread_get_all-threads failling the assertion at
>> > >>> > >> test_ti_instrum.c:80
>> > >>> > >>
>> > >>> > >> geir
>> > >>> > >>
>> > >>> > >> On Oct 8, 2006, at 7:19 AM, Evgueni Brevnov wrote:
>> > >>> > >>
>> > >>> > >> > While running cunit on Linux it turned out one test case
>> fails
>> > >>> some
>> > >>> > >> > time. The fix is in tests.final.2.patch.
>> > >>> > >> >
>> > >>> > >> > So the last versions to be committed:
>> > >>> > >> > invocation_api.final.patch
>> > >>> > >> > build.final.2.patch
>> > >>> > >> > tests.final.2.patch
>> > >>> > >> >
>> > >>> > >> > Evgueni
>> > >>> > >> >
>> > >>> > >> >
>> > >>> > >> > On 10/8/06, Evgueni Brevnov <ev...@gmail.com>
>> wrote:
>> > >>> > >> >> I mahaged to resolve the problem on Linux.... will update
>> > >>> > >> >> build.final.patch with build.final.2.patch in a while
>> > >>> > >> >>
>> > >>> > >> >> On 10/8/06, Evgueni Brevnov <ev...@gmail.com>
>> wrote:
>> > >>> > >> >> > Hi,
>> > >>> > >> >> >
>> > >>> > >> >> > Oh! Ooh! I did that..... I passed cunit, somke, kernel
>> > >>> tests on
>> > >>> > >> >> > Windows and smoke, kernel tests on Linux. Unfortunately I
>> > >>> > >> failed to
>> > >>> > >> >> > link cunit tests on Linux so far. So I disabled cunit
>> on Linux
>> > >>> > >> >> until
>> > >>> > >> >> > the problem is solved. I believe it is acceptable as
>> short
>> > >>> term
>> > >>> > >> >> > solution. I found several problems in cunit tests. I
>> will come
>> > >>> > >> >> up with
>> > >>> > >> >> > my findings later (not today).
>> > >>> > >> >> >
>> > >>> > >> >> > Use latest patches from HARMONY-1582. They are marked as
>> > >>> final.
>> > >>> > >> >> There
>> > >>> > >> >> > are three patches. One for build module, one for cunit
>> > >>> tests and
>> > >>> > >> >> one
>> > >>> > >> >> > for VM itself.
>> > >>> > >> >> >
>> > >>> > >> >> > Thanks
>> > >>> > >> >> > Evgueni
>> > >>> > >> >> >
>> > >>> > >> >> >
>> > >>> > >> >> > On 10/6/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>> > >>> > >> >> > > Nooooooo! LOL
>> > >>> > >> >> > >
>> > >>> > >> >> > > I'm here waiting - This will unblock a whole bunch of
>> > >>> > >> things :)
>> > >>> > >> >> > >
>> > >>> > >> >> > > Thanks for the effort
>> > >>> > >> >> > >
>> > >>> > >> >> > > Evgueni Brevnov wrote:
>> > >>> > >> >> > > > Geir,
>> > >>> > >> >> > > >
>> > >>> > >> >> > > > That's terrible. We have power outage....servers are
>> > >>> down. I
>> > >>> > >> >> can't
>> > >>> > >> >> > > > send the patches now.... will do it tomorrow
>> > >>> > >> >> > > >
>> > >>> > >> >> > > > Evgueni
>> > >>> > >> >> > > > On 10/5/06, Geir Magnusson Jr. <ge...@pobox.com>
>> wrote:
>> > >>> > >> >> > > >> woo hoo! here we go...
>> > >>> > >> >> > > >>
>> > >>> > >> >> > > >>
>> > >>> > >> >> > > >> Andrey Chernyshev wrote:
>> > >>> > >> >> > > >> > Hi Evgueni,
>> > >>> > >> >> > > >> >
>> > >>> > >> >> > > >> > On 10/4/06, Evgueni Brevnov
>> <ev...@gmail.com>
>> > >>> > >> >> wrote:
>> > >>> > >> >> > > >> >> Hi All,
>> > >>> > >> >> > > >> >>
>> > >>> > >> >> > > >> >> I have attached updated patch to the JIRA. It
>> should
>> > >>> > >> >> resolve remain
>> > >>> > >> >> > > >> >> concerns. Andrey, could you give a green light
>> now?
>> > >>> > >> >> > > >> >
>> > >>> > >> >> > > >> > Thanks for updating the patch! I agree it it
>> can be
>> > >>> > >> >> committed, at
>> > >>> > >> >> > > >> > least signatures look good. 5 revisions seem
>> like more
>> > >>> > >> >> than enough :).
>> > >>> > >> >> > > >> > Anyways, I think the remaining issues can be
>> resolved
>> > >>> > >> >> with additional
>> > >>> > >> >> > > >> > patches. Thanks again for the good work and your
>> > >>> > >> patience.
>> > >>> > >> >> > > >> >
>> > >>> > >> >> > > >> > Thanks,
>> > >>> > >> >> > > >> > Andrey.
>> > >>> > >> >> > > >> >
>> > >>> > >> >> > > >> >>
>> > >>> > >> >> > > >> >> Thanks
>> > >>> > >> >> > > >> >> Evgueni
>> > >>> > >> >> > > >> >>
>> > >>> > >> >> > > >> >> On 10/4/06, Evgueni Brevnov
>> > >>> <ev...@gmail.com>
>> > >>> > >> >> wrote:
>> > >>> > >> >> > > >> >> > Andrey,
>> > >>> > >> >> > > >> >> >
>> > >>> > >> >> > > >> >> > I see your points. I think both approaches have
>> > >>> > >> >> advantages and
>> > >>> > >> >> > > >> >> > disadvantages. I think it is quite hard to
>> say which
>> > >>> > >> >> approach is
>> > >>> > >> >> > > >> >> > better until we play with one VM only. I
>> still feel
>> > >>> > >> >> like introducing
>> > >>> > >> >> > > >> >> > one more dependence is better than spreading
>> code
>> > >>> > >> >> which deals with
>> > >>> > >> >> > > >> >> > attachment among VM and TM. We really get
>> stuck. OK,
>> > >>> > >> >> just because I
>> > >>> > >> >> > > >> >> > want to move forward I will do required
>> changes to
>> > >>> > >> remove
>> > >>> > >> >> > > >> >> > vm_create_jthread from TM. I believe that will
>> > >>> resolve
>> > >>> > >> >> all our
>> > >>> > >> >> > > >> >> > disagreements and the patch will be applied
>> soon.
>> > >>> > >> >> > > >> >> >
>> > >>> > >> >> > > >> >> >
>> > >>> > >> >> > > >> >> > Thanks
>> > >>> > >> >> > > >> >> > Evgueni.
>> > >>> > >> >> > > >> >> >
>> > >>> > >> >> > > >> >> > On 10/4/06, Andrey Chernyshev
>> > >>> > >> >> <a....@gmail.com> wrote:
>> > >>> > >> >> > > >> >> > > On 10/3/06, Evgueni Brevnov
>> > >>> > >> >> <ev...@gmail.com> wrote:
>> > >>> > >> >> > > >> >> > > > On 10/3/06, Andrey Chernyshev
>> > >>> > >> >> <a....@gmail.com> wrote:
>> > >>> > >> >> > > >> >> > > > > On 10/2/06, Evgueni Brevnov
>> > >>> > >> >> <ev...@gmail.com> wrote:
>> > >>> > >> >> > > >> >> > > > > > Andrey,
>> > >>> > >> >> > > >> >> > > > > >
>> > >>> > >> >> > > >> >> > > > > > Just to be clear.... I agree with
>> you it is
>> > >>> > >> more
>> > >>> > >> >> > > >> convenient if
>> > >>> > >> >> > > >> >> > > > > > jthread_create takes JNIEnv instead of
>> > >>> > >> JavaVM. It
>> > >>> > >> >> > > >> reflects that
>> > >>> > >> >> > > >> >> > > > > > current thread has been attached
>> already. Do
>> > >>> > >> >> you think it
>> > >>> > >> >> > > >> >> makes sense
>> > >>> > >> >> > > >> >> > > > > > to get rid of JNIEnv and use
>> > >>> > >> >> jthread_get_JNI_env in that
>> > >>> > >> >> > > >> case?
>> > >>> > >> >> > > >> >> > > > >
>> > >>> > >> >> > > >> >> > > > > The jthread_* layer is designed like
>> if it
>> > >>> were
>> > >>> > >> >> a regular JNI
>> > >>> > >> >> > > >> >> > > > > application which is meant to be called
>> > >>> from the
>> > >>> > >> >> Java code,
>> > >>> > >> >> > > >> hence
>> > >>> > >> >> > > >> >> > > > > every function on that layer receives
>> > >>> JNIenv. We
>> > >>> > >> >> can probably
>> > >>> > >> >> > > >> >> get rid
>> > >>> > >> >> > > >> >> > > > > of the JNEnv parameter for jthread_*
>> > >>> functions,
>> > >>> > >> >> assuming that
>> > >>> > >> >> > > >> >> TM can
>> > >>> > >> >> > > >> >> > > > > always extract JNIenv for the current
>> thread
>> > >>> > >> with
>> > >>> > >> >> > > >> >> > > > > jthread_get_JNI_env().
>> > >>> > >> >> > > >> >> > > > > My only concern would be the
>> performance -
>> > >>> once
>> > >>> > >> >> the JNIenv is
>> > >>> > >> >> > > >> >> already
>> > >>> > >> >> > > >> >> > > > > known for the native part of the kernel
>> > >>> classes
>> > >>> > >> >> impl, it
>> > >>> > >> >> > > >> must be
>> > >>> > >> >> > > >> >> > > > > cheaper to pass JNIEnv to TM as an extra
>> > >>> > >> >> parameter rather than
>> > >>> > >> >> > > >> >> extract
>> > >>> > >> >> > > >> >> > > > > it from the TLS again.
>> > >>> > >> >> > > >> >> > > > > Other than that, I see no strong
>> advantages in
>> > >>> > >> >> keeping JNIEnv
>> > >>> > >> >> > > >> >> parameter.
>> > >>> > >> >> > > >> >> > > > >
>> > >>> > >> >> > > >> >> > > > >
>> > >>> > >> >> > > >> >> > > > > > Regarding jthread_attach. I still
>> didn't get
>> > >>> > >> >> your point....
>> > >>> > >> >> > > >> >> Clarify it
>> > >>> > >> >> > > >> >> > > > > > please if you think jhread_attach
>> should be
>> > >>> > >> >> modified.
>> > >>> > >> >> > > >> >> > > > >
>> > >>> > >> >> > > >> >> > > > > Sorry for being not clear: I think for
>> > >>> > >> >> jthread_attach, we have
>> > >>> > >> >> > > >> >> two options:
>> > >>> > >> >> > > >> >> > > > > 1) Make JNIEnv input parameter - it
>> must be
>> > >>> new
>> > >>> > >> >> JNIEnv that VM
>> > >>> > >> >> > > >> >> > > > > pre-allocates for the new Java thread.
>> > >>> > >> >> jthread_attach
>> > >>> > >> >> > > >> would just
>> > >>> > >> >> > > >> >> > > > > associate it with the current thread.
>> > >>> > >> >> > > >> >> > > > >
>> > >>> > >> >> > > >> >> > > > > 2) Obtain JNIEnv via vm_attach()
>> callback. In
>> > >>> > >> >> this case, if
>> > >>> > >> >> > > >> >> > > > > vm_attach() callback implementation
>> needs to
>> > >>> > >> >> know for which
>> > >>> > >> >> > > >> >> JavaVM new
>> > >>> > >> >> > > >> >> > > > > JNIenv has to be allocated, then we'll
>> need to
>> > >>> > >> >> add JavaVM as
>> > >>> > >> >> > > >> >> input
>> > >>> > >> >> > > >> >> > > > > parameter for jthread_attach().
>> > >>> > >> >> > > >> >> > > > > I think both options should be fine,
>> (1) would
>> > >>> > >> >> probably
>> > >>> > >> >> > > >> keep TM
>> > >>> > >> >> > > >> >> > > > > interface a bit lighter, though (2)
>> may look
>> > >>> > >> >> more closer to
>> > >>> > >> >> > > >> >> the JNI
>> > >>> > >> >> > > >> >> > > > > invocation API idea.
>> > >>> > >> >> > > >> >> > > > > So I think adding JavaVM specifically for
>> > >>> > >> >> jthread_attach
>> > >>> > >> >> > > >> may make
>> > >>> > >> >> > > >> >> > > > > sense given the explanation you provided
>> > >>> > >> earlier.
>> > >>> > >> >> > > >> >> > > > >
>> > >>> > >> >> > > >> >> > > > > The concern I would have regarding the
>> > >>> proposed
>> > >>> > >> >> jthread_attach
>> > >>> > >> >> > > >> >> > > > > implementation is a call to
>> > >>> vm_create_jthread()
>> > >>> > >> >> - this call
>> > >>> > >> >> > > >> >> introduces
>> > >>> > >> >> > > >> >> > > > > an extra dependency of TM on vmcore
>> that I'd
>> > >>> > >> >> prefer to be
>> > >>> > >> >> > > >> >> avoided. In
>> > >>> > >> >> > > >> >> > > > > the original version, jthread_attach()
>> was
>> > >>> > >> >> taking jthread
>> > >>> > >> >> > > >> >> argument of
>> > >>> > >> >> > > >> >> > > > > the already prepared j.l.Thread.
>> > >>> > >> >> > > >> >> > > >
>> > >>> > >> >> > > >> >> > > > I understand your concern. Unfortunately
>> I don't
>> > >>> > >> >> see what we
>> > >>> > >> >> > > >> can do
>> > >>> > >> >> > > >> >> > > > here. Let me explain. In the beginning you
>> > >>> have an
>> > >>> > >> >> unattached
>> > >>> > >> >> > > >> >> native
>> > >>> > >> >> > > >> >> > > > thread. To be able to call java code
>> (which is
>> > >>> > >> >> required for
>> > >>> > >> >> > > >> >> > > > constructing j.l.Thread instance) the
>> thread
>> > >>> > >> >> should be attached
>> > >>> > >> >> > > >> >> first.
>> > >>> > >> >> > > >> >> > > > To be specific it should be attached to
>> VM by
>> > >>> > >> >> calling vm_attach
>> > >>> > >> >> > > >> >> which
>> > >>> > >> >> > > >> >> > > > will return a valid JNIEnv It is valid
>> to use
>> > >>> JNI
>> > >>> > >> >> from that
>> > >>> > >> >> > > >> moment.
>> > >>> > >> >> > > >> >> > > > Obtained JNIEnv can be used to execute
>> java code
>> > >>> > >> >> and create
>> > >>> > >> >> > > >> >> j.l.Thread
>> > >>> > >> >> > > >> >> > > > instance. Since we do vm_attach in
>> > >>> jthread_attach
>> > >>> > >> >> we need to do
>> > >>> > >> >> > > >> >> > > > vm_create_jthread inside jthread_atach
>> as well.
>> > >>> > >> >> > > >> >> > > > Of course it can be an alternative to do
>> > >>> vm_attach
>> > >>> > >> >> and
>> > >>> > >> >> > > >> >> > > > vm_create_jthread outside of TM right
>> before
>> > >>> > >> >> jthread_attach.
>> > >>> > >> >> > > >> >> Sure it
>> > >>> > >> >> > > >> >> > > > will reduce one dependence between VM
>> and TM.
>> > >>> But
>> > >>> > >> >> it seems like
>> > >>> > >> >> > > >> >> > > > artificial action for me just because of
>> > >>> > >> >> dependency....
>> > >>> > >> >> > > >> >> > >
>> > >>> > >> >> > > >> >> > > Why do you think it is artificial? I would
>> rather
>> > >>> > >> >> prefer not to
>> > >>> > >> >> > > >> throw
>> > >>> > >> >> > > >> >> > > vm_attach event from the jthread_attach()
>> call at
>> > >>> > >> >> all than to add
>> > >>> > >> >> > > >> >> > > extra dependency. The idea of jthread
>> layer is a
>> > >>> > >> >> Java face to
>> > >>> > >> >> > > >> >> > > hythread, it is meant to know either a
>> little or
>> > >>> > >> >> nothing about the
>> > >>> > >> >> > > >> >> > > rest of VM. It may be logical to throw
>> vm_attach
>> > >>> > >> >> call from the
>> > >>> > >> >> > > >> newly
>> > >>> > >> >> > > >> >> > > created thread, because there is no other way
>> > >>> to let
>> > >>> > >> >> know VM
>> > >>> > >> >> > > >> the new
>> > >>> > >> >> > > >> >> > > thread is created. VM attach is a
>> different case -
>> > >>> > >> >> VM already
>> > >>> > >> >> > > >> knows
>> > >>> > >> >> > > >> >> > > about new Java thread at the time of the
>> > >>> > >> >> AttachCurrentThread call.
>> > >>> > >> >> > > >> >> > >
>> > >>> > >> >> > > >> >> > > >
>> > >>> > >> >> > > >> >> > > > > Do you think it makes sense to replace a
>> > >>> single
>> > >>> > >> >> jthread
>> > >>> > >> >> > > >> >> parameter with
>> > >>> > >> >> > > >> >> > > > > a variety of stuff (like thread group,
>> > >>> name)? It
>> > >>> > >> >> seems the
>> > >>> > >> >> > > >> only
>> > >>> > >> >> > > >> >> > > > > purpose of at these args is to be passed
>> > >>> back to
>> > >>> > >> >> VM for
>> > >>> > >> >> > > >> >> > > > > vm_jthread_create(). I would suggest
>> to change
>> > >>> > >> >> this and try
>> > >>> > >> >> > > >> doing
>> > >>> > >> >> > > >> >> > > > > either of:
>> > >>> > >> >> > > >> >> > > > > 1) Make signature of jthread_attach
>> with 3
>> > >>> args,
>> > >>> > >> >> JavaVM,
>> > >>> > >> >> > > >> >> jthread and the daemon.
>> > >>> > >> >> > > >> >> > > > Why do you want to pass daemon to TM but
>> > >>> thread's
>> > >>> > >> >> name and
>> > >>> > >> >> > > >> >> group. Just
>> > >>> > >> >> > > >> >> > > > because current TM doesn't need such
>> > >>> information?
>> > >>> > >> >> What if it is
>> > >>> > >> >> > > >> >> > > > required to get thread name later? Say by
>> > >>> > >> introducing
>> > >>> > >> >> > > >> >> > >
>> > >>> > >> >> > > >> >> > > I imagine you need a daemon attribute
>> since the TM
>> > >>> > >> >> is still
>> > >>> > >> >> > > >> managing
>> > >>> > >> >> > > >> >> > > the thread daemonality. TM is not managing
>> thread
>> > >>> > >> >> name and group -
>> > >>> > >> >> > > >> >> > > they are all kept on the Java level, hence
>> passing
>> > >>> > >> >> them may be
>> > >>> > >> >> > > >> >> > > excessive.
>> > >>> > >> >> > > >> >> > >
>> > >>> > >> >> > > >> >> > > > jthread_get_name... What will you do in
>> that
>> > >>> case?
>> > >>> > >> >> Let me
>> > >>> > >> >> > > >> guess you
>> > >>> > >> >> > > >> >> > > > will call j.l.Thread.getName. Right. Ok!
>> In that
>> > >>> > >> >> case I see no
>> > >>> > >> >> > > >> >> > > > problems to call j.l.Thread.isDaemon. Do
>> you
>> > >>> > >> >> agree? So it
>> > >>> > >> >> > > >> doesn't
>> > >>> > >> >> > > >> >> > >
>> > >>> > >> >> > > >> >> > > As I suggested earlier, the best way to
>> handle
>> > >>> > >> >> daemonality would
>> > >>> > >> >> > > >> >> > > probably be in pure Java - in j.l.Thread (or
>> > >>> > >> >> > > >> j.l.VMThreadManager) or
>> > >>> > >> >> > > >> >> > > whatever. You already lifted it up to the
>> jthread
>> > >>> > >> >> level, but
>> > >>> > >> >> > > >> what if
>> > >>> > >> >> > > >> >> > > we can go a little bit higher...
>> > >>> > >> >> > > >> >> > >
>> > >>> > >> >> > > >> >> > > > seems to be a good design to pass only part
>> > >>> of the
>> > >>> > >> >> > > >> information to
>> > >>> > >> >> > > >> >> > > > jthread_atach. Lets look at the
>> signature of
>> > >>> > >> >> > > >> >> AttachCurrentThread. It
>> > >>> > >> >> > > >> >> > > > takes exactly these three parameters
>> (daemon,
>> > >>> > >> >> name, group)
>> > >>> > >> >> > > >> >> passed as a
>> > >>> > >> >> > > >> >> > > > structure. I was thinking about having
>> > >>> exactly the
>> > >>> > >> >> same
>> > >>> > >> >> > > >> >> structure as
>> > >>> > >> >> > > >> >> > > > third parameter of jthread_attach but it
>> occured
>> > >>> > >> >> to be more
>> > >>> > >> >> > > >> >> convinient
>> > >>> > >> >> > > >> >> > > > to pass them seperatly. Although I don't
>> see
>> > >>> > >> >> strong reasons
>> > >>> > >> >> > > >> against
>> > >>> > >> >> > > >> >> > > > having a structure a third parameter.
>> > >>> > >> >> > > >> >> > >
>> > >>> > >> >> > > >> >> > > I see. Acually, I would love to keep the
>> > >>> > >> >> jthread_attach func-ty at
>> > >>> > >> >> > > >> >> the
>> > >>> > >> >> > > >> >> > > minimum level which will be needed to
>> handle the
>> > >>> > >> >> only data that TM
>> > >>> > >> >> > > >> >> > > should be aware of. We need a formal boundary
>> > >>> > >> >> between jthread
>> > >>> > >> >> > > >> layer
>> > >>> > >> >> > > >> >> > > and vmcore (otherwise jthread won't have a
>> much of
>> > >>> > >> >> sense, one may
>> > >>> > >> >> > > >> >> > > consider it just as a convenience set of
>> functions
>> > >>> > >> >> in vmcore which
>> > >>> > >> >> > > >> >> are
>> > >>> > >> >> > > >> >> > > doing something with threading).
>> > >>> > >> >> > > >> >> > >
>> > >>> > >> >> > > >> >> > > >
>> > >>> > >> >> > > >> >> > > > > 2) Move the implementation of
>> > >>> vm_create_jtrhead
>> > >>> > >> >> () to
>> > >>> > >> >> > > >> >> > > > > thread_java_basic.c - could it be
>> written in
>> > >>> > >> >> pure JNI without
>> > >>> > >> >> > > >> >> using
>> > >>> > >> >> > > >> >> > > > > internal VM API like
>> class_alloc_new_object()?
>> > >>> > >> >> > > >> >> > > >
>> > >>> > >> >> > > >> >> > > > Yes, this can be done but it doesn't fix
>> the
>> > >>> > >> >> problem. You still
>> > >>> > >> >> > > >> >> need
>> > >>> > >> >> > > >> >> > > > to know about internal constructor of
>> j.l.Thread
>> > >>> > >> >> > > >> >> > >
>> > >>> > >> >> > > >> >> > > That's bad. Given what you said, now it
>> seems that
>> > >>> > >> >> the most
>> > >>> > >> >> > > >> >> preferable
>> > >>> > >> >> > > >> >> > > sequence for AttachCurrentThread impl still
>> > >>> would be
>> > >>> > >> >> like:
>> > >>> > >> >> > > >> >> > > JNIEnv = vm_attach();
>> > >>> > >> >> > > >> >> > > jthread = create_jthread(JNIenv)
>> > >>> > >> >> > > >> >> > > jthread_attach(JNIEnv, jthread) // stores
>> > >>> JNIEnv and
>> > >>> > >> >> Hythread into
>> > >>> > >> >> > > >> >> > > TLS, doesn't call vm_attach any longer.
>> > >>> > >> >> > > >> >> > > - this is almost what we had from the
>> beginning...
>> > >>> > >> >> > > >> >> > >
>> > >>> > >> >> > > >> >> > > Thanks,
>> > >>> > >> >> > > >> >> > > Andrey.
>> > >>> > >> >> > > >> >> > >
>> > >>> > >> >> > > >> >> > > >
>> > >>> > >> >> > > >> >> > > >
>> > >>> > >> >> > > >> >> > > > Thanks
>> > >>> > >> >> > > >> >> > > > Evgueni
>> > >>> > >> >> > > >> >> > > > >
>> > >>> > >> >> > > >> >> > > > >
>> > >>> > >> >> > > >> >> > > > > Thanks,
>> > >>> > >> >> > > >> >> > > > > Andrey.
>> > >>> > >> >> > > >> >> > > > >
>> > >>> > >> >> > > >> >> > > > > >
>> > >>> > >> >> > > >> >> > > > > > Thank you
>> > >>> > >> >> > > >> >> > > > > > Evgueni
>> > >>> > >> >> > > >> >> > > > > >
>> > >>> > >> >> > > >> >> > > > > > On 10/2/06, Evgueni Brevnov
>> > >>> > >> >> <ev...@gmail.com>
>> > >>> > >> >> > > >> wrote:
>> > >>> > >> >> > > >> >> > > > > > > On 9/29/06, Andrey Chernyshev
>> > >>> > >> >> <a....@gmail.com>
>> > >>> > >> >> > > >> >> wrote:
>> > >>> > >> >> > > >> >> > > > > > > > On 9/29/06, Evgueni Brevnov
>> > >>> > >> >> <ev...@gmail.com>
>> > >>> > >> >> > > >> >> wrote:
>> > >>> > >> >> > > >> >> > > > > > > > > Artem,
>> > >>> > >> >> > > >> >> > > > > > > > >
>> > >>> > >> >> > > >> >> > > > > > > > > Thank you for your feedback....
>> > >>> find my
>> > >>> > >> >> inlined.....
>> > >>> > >> >> > > >> >> > > > > > > > >
>> > >>> > >> >> > > >> >> > > > > > > > > On 9/29/06, Artem Aliev
>> > >>> > >> >> <ar...@gmail.com> wrote:
>> > >>> > >> >> > > >> >> > > > > > > > > > Evgueni,
>> > >>> > >> >> > > >> >> > > > > > > > > >
>> > >>> > >> >> > > >> >> > > > > > > > > > I got most of your changes, but
>> > >>> still
>> > >>> > >> >> disagree
>> > >>> > >> >> > > >> with all
>> > >>> > >> >> > > >> >> > > > > > > > > > hythread/jthread interface
>> changes.
>> > >>> > >> >> Could leave
>> > >>> > >> >> > > >> >> interface unchanged.
>> > >>> > >> >> > > >> >> > > > > > > > > > See following possible
>> solutions,
>> > >>> that
>> > >>> > >> >> could solve
>> > >>> > >> >> > > >> >> the same problems
>> > >>> > >> >> > > >> >> > > > > > > > > > without interface changes.
>> > >>> > >> >> > > >> >> > > > > > > > > >
>> > >>> > >> >> > > >> >> > > > > > > > > >
>> > >>> > >> >> > > >> >> > > > > > > > > > 1) daemon attribute is a java
>> > >>> > >> >> specific. (Andrey
>> > >>> > >> >> > > >> >> mentioned this already).
>> > >>> > >> >> > > >> >> > > > > > > > > > Could you please move it
>> back. to
>> > >>> > >> >> the jthread
>> > >>> > >> >> > > >> >> layer. It is better
>> > >>> > >> >> > > >> >> > > > > > > > > > to rename
>> > >>> > >> >> > > >> >> > > > > > > > > >
>> > >>> > >> >> hythread_wait_for_all_nondaemon_threads() to
>> > >>> > >> >> > > >> >> > > > > > > > > >
>> > >>> > >> jthread_wait_for_all_nondaemon_threads().
>> > >>> > >> >> > > >> >> > > > > > > > > Ok, I see no problems to move
>> "daemon"
>> > >>> > >> >> to java layer.
>> > >>> > >> >> > > >> >> In that case:
>> > >>> > >> >> > > >> >> > > > > > > > > 1) I will move
>> > >>> > >> >> > > >> >> hythread_wait_for_all_nondaemon_threads() from
>> > >>> > >> >> > > >> >> > > > > > > > > thread_init.c to one which
>> implements
>> > >>> > >> >> java layer.
>> > >>> > >> >> > > >> >> > > > > > > > > 2) I will move daemon field from
>> > >>> > >> >> HyThread structure.
>> > >>> > >> >> > > >> >> > > > > > > > >
>> > >>> > >> >> > > >> >> > > > > > > > > Agree?
>> > >>> > >> >> > > >> >> > > > > > > >
>> > >>> > >> >> > > >> >> > > > > > > > Sounds good to me.
>> > >>> > >> >> > > >> >> > > > > > >
>> > >>> > >> >> > > >> >> > > > > > > OK, will do that.
>> > >>> > >> >> > > >> >> > > > > > >
>> > >>> > >> >> > > >> >> > > > > > > >
>> > >>> > >> >> > > >> >> > > > > > > >
>> > >>> > >> >> > > >> >> > > > > > > > >
>> > >>> > >> >> > > >> >> > > > > > > > > >
>> > >>> > >> >> > > >> >> > > > > > > > > > 2) JavaVM could be
>> retrieved from
>> > >>> > >> >> JNIEnv by
>> > >>> > >> >> > > >> >> jni_get_java_vm(). So
>> > >>> > >> >> > > >> >> > > > > > > > > > let the jthread_create() and
>> > >>> others to
>> > >>> > >> >> use JNIEnv
>> > >>> > >> >> > > >> >> (that is passed from
>> > >>> > >> >> > > >> >> > > > > > > > > > java native method).
>> > >>> > >> >> > > >> >> > > > > > > > > > The vm_attach could get old
>> JNI env
>> > >>> > >> >> and create new
>> > >>> > >> >> > > >> >> one for the new thread.
>> > >>> > >> >> > > >> >> > > > > > > > > > The first JNIEnv is created in
>> > >>> > >> >> CreateVM call and
>> > >>> > >> >> > > >> >> could be passed to
>> > >>> > >> >> > > >> >> > > > > > > > > > the first thread at startup.
>> > >>> > >> >> > > >> >> > > > > > > > > No, no, no. I completely
>> disagree with
>> > >>> > >> >> that!!! Why do
>> > >>> > >> >> > > >> >> you like JNIEnv
>> > >>> > >> >> > > >> >> > > > > > > > > but JavaVM. Why do you think that
>> > >>> > >> >> passing JavaVM
>> > >>> > >> >> > > >> >> instead of JNIEnv
>> > >>> > >> >> > > >> >> > > > > > > > > makes TM less modular? I don't
>> see any
>> > >>> > >> >> difference
>> > >>> > >> >> > > >> >> here.... It seems
>> > >>> > >> >> > > >> >> > > > > > > > > for me like a big big hack to
>> grab
>> > >>> > >> >> JNIEnv from another
>> > >>> > >> >> > > >> >> thread and pass
>> > >>> > >> >> > > >> >> > > > > > > > > it to jthread_attach to perform
>> > >>> > >> >> operations in the
>> > >>> > >> >> > > >> >> current thread.
>> > >>> > >> >> > > >> >> > > > > > > >
>> > >>> > >> >> > > >> >> > > > > > > > TM needs to know JNIEnv, mainly for
>> > >>> > >> >> managing the
>> > >>> > >> >> > > >> >> references to
>> > >>> > >> >> > > >> >> > > > > > > > objects, throwing exceptions and
>> calling
>> > >>> > >> >> run() method of
>> > >>> > >> >> > > >> >> a new thread.
>> > >>> > >> >> > > >> >> > > > > > > > JNI spec proposes that JNIEnv is
>> valid
>> > >>> > >> >> within the given
>> > >>> > >> >> > > >> >> thread, this
>> > >>> > >> >> > > >> >> > > > > > > > is why TM holds the JNIEnv
>> pointer at
>> > >>> the
>> > >>> > >> >> moment. This
>> > >>> > >> >> > > >> >> is why TM likes
>> > >>> > >> >> > > >> >> > > > > > > > the JNIEnv.
>> > >>> > >> >> > > >> >> > > > > > > >
>> > >>> > >> >> > > >> >> > > > > > > > Having the JNIEnv, one is able
>> to get
>> > >>> > >> >> JavaVM but not
>> > >>> > >> >> > > >> >> vise versa. This
>> > >>> > >> >> > > >> >> > > > > > > > is why TM doesn't like the
>> JavaVM :)
>> > >>> > >> >> > > >> >> > > > > > > I see your point. Only one note
>> this is
>> > >>> true
>> > >>> > >> >> for already
>> > >>> > >> >> > > >> >> attached threads...
>> > >>> > >> >> > > >> >> > > > > > >
>> > >>> > >> >> > > >> >> > > > > > > >
>> > >>> > >> >> > > >> >> > > > > > > > I agree with you that there is a
>> design
>> > >>> > >> >> flaw that the
>> > >>> > >> >> > > >> >> JNIEnv is copied
>> > >>> > >> >> > > >> >> > > > > > > > from the parent thread to a
>> child thread
>> > >>> > >> >> during thread
>> > >>> > >> >> > > >> >> creation. I
>> > >>> > >> >> > > >> >> > > > > > > > think it could be resolved via
>> > >>> vm_attach()
>> > >>> > >> >> hook - with
>> > >>> > >> >> > > >> >> this event, VM
>> > >>> > >> >> > > >> >> > > > > > > > might tell the TM what the JNIEnv
>> > >>> pointer
>> > >>> > >> >> for new thread
>> > >>> > >> >> > > >> >> should be. I
>> > >>> > >> >> > > >> >> > > > > > > > think you did that by extending the
>> > >>> > >> >> vm_attach() call
>> > >>> > >> >> > > >> >> with the JNIEnv**
>> > >>> > >> >> > > >> >> > > > > > > > argument.
>> > >>> > >> >> > > >> >> > > > > > > >
>> > >>> > >> >> > > >> >> > > > > > > > What is not completely clear is,
>> why do
>> > >>> > >> >> you have to pass
>> > >>> > >> >> > > >> >> the JavaVM
>> > >>> > >> >> > > >> >> > > > > > > > forth and back, once from VM to
>> TM, and
>> > >>> > >> >> then back from
>> > >>> > >> >> > > >> >> TM to VM again?
>> > >>> > >> >> > > >> >> > > > > > > >
>> > >>> > >> >> > > >> >> > > > > > > > If you need to know in
>> jthread_attach,
>> > >>> > >> >> which particular
>> > >>> > >> >> > > >> >> VM vm_attach()
>> > >>> > >> >> > > >> >> > > > > > > > event is coming from, you could
>> have
>> > >>> > >> >> vm_attach like
>> > >>> > >> >> > > >> >> > > > > > > > vm_attach(JNIEnv* currentThreadEnv,
>> > >>> > >> JNIEnv**
>> > >>> > >> >> > > >> >> newThreadEnv).
>> > >>> > >> >> > > >> >> > > > > > > I'm a little bit confused.....Current
>> > >>> thread
>> > >>> > >> >> hasn't been
>> > >>> > >> >> > > >> >> attached yet.
>> > >>> > >> >> > > >> >> > > > > > > So there is no JNIEnv for it yet. How
>> > >>> it can
>> > >>> > >> >> be passed as
>> > >>> > >> >> > > >> >> the first
>> > >>> > >> >> > > >> >> > > > > > > parameter to vm_attach()?
>> > >>> > >> >> > > >> >> > > > > > >
>> > >>> > >> >> > > >> >> > > > > > > > Then you will be always able to
>> get the
>> > >>> > >> >> JavaVM from the
>> > >>> > >> >> > > >> >> JNIEnv.
>> > >>> > >> >> > > >> >> > > > > > > > The only difference is that you are
>> > >>> > >> >> currently doing
>> > >>> > >> >> > > >> >> JNIEnv->JavaVM
>> > >>> > >> >> > > >> >> > > > > > > > conversion in the VMThreadManager,
>> > >>> but why
>> > >>> > >> >> can't you
>> > >>> > >> >> > > >> >> just do this in
>> > >>> > >> >> > > >> >> > > > > > > > vm_attach() without changing the
>> > >>> interface
>> > >>> > >> >> of the TM?
>> > >>> > >> >> > > >> >> > > > > > > > So far JavaVM really looks like
>> an extra
>> > >>> > >> >> knowledge that
>> > >>> > >> >> > > >> >> TM doesn't
>> > >>> > >> >> > > >> >> > > > > > > > have to be aware of.
>> > >>> > >> >> > > >> >> > > > > > > >
>> > >>> > >> >> > > >> >> > > > > > > > > Moreover there is no JNIEnv
>> when main
>> > >>> > >> >> thread attaches
>> > >>> > >> >> > > >> >> to VM. So we
>> > >>> > >> >> > > >> >> > > > > > > > > should either keep it as is or
>> change
>> > >>> > >> >> original design
>> > >>> > >> >> > > >> >> of TM and attach
>> > >>> > >> >> > > >> >> > > > > > > > > thread to VM before attaching
>> it to
>> > >>> TM.
>> > >>> > >> >> In that case
>> > >>> > >> >> > > >> >> we will have
>> > >>> > >> >> > > >> >> > > > > > > > > valid JNIEnv which can be
>> passed to
>> > >>> > >> >> jthread_atatch. We
>> > >>> > >> >> > > >> >> need to think
>> > >>> > >> >> > > >> >> > > > > > > > > over it twice before changing
>> > >>> > >> something....
>> > >>> > >> >> > > >> >> > > > > > > >
>> > >>> > >> >> > > >> >> > > > > > > > Right. For jthread_attach, JNIenv
>> > >>> needs to
>> > >>> > >> >> be changed
>> > >>> > >> >> > > >> >> from being input
>> > >>> > >> >> > > >> >> > > > > > > > parameter to being the output
>> parameter.
>> > >>> > >> >> The way how
>> > >>> > >> >> > > >> >> JNIenv is
>> > >>> > >> >> > > >> >> > > > > > > > obtained by TM should be
>> vm_attach()
>> > >>> > >> event.
>> > >>> > >> >> > > >> >> > > > > > > OK, JNIEnv is output parameter.
>> And it
>> > >>> > >> >> obtained by
>> > >>> > >> >> > > >> >> vm_attach(). This
>> > >>> > >> >> > > >> >> > > > > > > is exactly like I do in the patch.
>> What I
>> > >>> > >> >> don't understand
>> > >>> > >> >> > > >> >> is how
>> > >>> > >> >> > > >> >> > > > > > > jthread_attach knows to which VM the
>> > >>> thread
>> > >>> > >> >> should be
>> > >>> > >> >> > > >> >> attached? Do you
>> > >>> > >> >> > > >> >> > > > > > > suggest calling vm_attach first to
>> create
>> > >>> > >> >> JNIEnv it pass
>> > >>> > >> >> > > >> >> it to
>> > >>> > >> >> > > >> >> > > > > > > jthread_attach?
>> > >>> > >> >> > > >> >> > > > > > >
>> > >>> > >> >> > > >> >> > > > > > > >
>> > >>> > >> >> > > >> >> > > > > > > > >
>> > >>> > >> >> > > >> >> > > > > > > > >
>> > >>> > >> >> > > >> >> > > > > > > > >
>> > >>> > >> >> > > >> >> > > > > > > > > >
>> > >>> > >> >> > > >> >> > > > > > > > > >
>> > >>> > >> >> > > >> >> > > > > > > > > > 4) Original classlib
>> hythread do
>> > >>> > >> not use
>> > >>> > >> >> > > >> >> hythread_library_t in arguments,
>> > >>> > >> >> > > >> >> > > > > > > > > > It uses following code:
>> > >>> > >> >> > > >> >> > > > > > > > > >
>> > >>> > >> >> > > >> >> > > > > > > > > > hythread_library_t lib =
>> > >>> GLOBAL_DATA
>> > >>> > >> >> > > >> >> (default_library);
>> > >>> > >> >> > > >> >> > > > > > > > > > or
>> > >>> > >> >> > > >> >> > > > > > > > > > hythread_library_t library =
>> > >>> thread-
>> > >>> > >> >> >library;
>> > >>> > >> >> > > >> >> > > > > > > > > >
>> > >>> > >> >> > > >> >> > > > > > > > > > So could you please use the
>> same
>> > >>> > >> >> mechanism and
>> > >>> > >> >> > > >> >> remove hythread_*_ex >functions.
>> > >>> > >> >> > > >> >> > > > > > > > > Let's see if classlib's
>> hythread needs
>> > >>> > >> >> changing first.
>> > >>> > >> >> > > >> >> It seems for me
>> > >>> > >> >> > > >> >> > > > > > > > > such code prevents us from having
>> > >>> > >> multi VM.
>> > >>> > >> >> > > >> >> > > > > > > > >
>> > >>> > >> >> > > >> >> > > > > > > > > >
>> > >>> > >> >> > > >> >> > > > > > > > > > 5. You introduce more then
>> one jni
>> > >>> > >> >> env, but still
>> > >>> > >> >> > > >> >> use global variable for it.
>> > >>> > >> >> > > >> >> > > > > > > > > > So all changes like following:
>> > >>> > >> >> > > >> >> > > > > > > > > > - JNIEnv *jenv = (JNIEnv*)
>> > >>> > >> >> jni_native_intf;
>> > >>> > >> >> > > >> >> > > > > > > > > > + JNIEnv *jenv =
>> jni_native_intf;
>> > >>> > >> >> > > >> >> > > > > > > > > >
>> > >>> > >> >> > > >> >> > > > > > > > > > should be like:
>> > >>> > >> >> > > >> >> > > > > > > > > > - JNIEnv *jenv = (JNIEnv*)
>> > >>> > >> >> jni_native_intf;
>> > >>> > >> >> > > >> >> > > > > > > > > > + JNIEnv *jenv = get_jni_env
>> > >>> > >> >> (jthread_self());
>> > >>> > >> >> > > >> >> > > > > > > > >
>> > >>> > >> >> > > >> >> > > > > > > > > Ok, I see. I agree that global
>> > >>> > >> >> jni_native_intf should
>> > >>> > >> >> > > >> >> not be used.
>> > >>> > >> >> > > >> >> > > > > > > > > There was simple reason why I
>> altered
>> > >>> > >> >> such lines.
>> > >>> > >> >> > > >> >> Because I changed
>> > >>> > >> >> > > >> >> > > > > > > > > the type of jni_native_intf
>> and no
>> > >>> > >> >> casting operator
>> > >>> > >> >> > > >> >> is needed now. To
>> > >>> > >> >> > > >> >> > > > > > > > > be honest I think get_jni_env
>> > >>> > >> >> (jthread_self()) can be
>> > >>> > >> >> > > >> >> good as temporary
>> > >>> > >> >> > > >> >> > > > > > > > > solution only. Lets wait for
>> design of
>> > >>> > >> >> multi VM and
>> > >>> > >> >> > > >> >> fix it according
>> > >>> > >> >> > > >> >> > > > > > > > > to it.
>> > >>> > >> >> > > >> >> > > > > > > >
>> > >>> > >> >> > > >> >> > > > > > > > While we are in JNI code, we
>> always have
>> > >>> > >> >> the JNIenv (at
>> > >>> > >> >> > > >> >> least
>> > >>> > >> >> > > >> >> > > > > > > > initially it comes from Java code).
>> > >>> If we
>> > >>> > >> >> consider VM
>> > >>> > >> >> > > >> >> code as if it
>> > >>> > >> >> > > >> >> > > > > > > > was a JNI application, then it
>> seems
>> > >>> like
>> > >>> > >> >> we should be
>> > >>> > >> >> > > >> >> just passing
>> > >>> > >> >> > > >> >> > > > > > > > JNIEnv as a parameter to all
>> > >>> functions in
>> > >>> > >> >> VM. Or, we can
>> > >>> > >> >> > > >> >> be taking it
>> > >>> > >> >> > > >> >> > > > > > > > from TLS (via jthread_self()),
>> depending
>> > >>> > >> >> on which way is
>> > >>> > >> >> > > >> >> faster...
>> > >>> > >> >> > > >> >> > > > > > > Agree.
>> > >>> > >> >> > > >> >> > > > > > >
>> > >>> > >> >> > > >> >> > > > > > > >
>> > >>> > >> >> > > >> >> > > > > > > > >
>> > >>> > >> >> > > >> >> > > > > > > > > >
>> > >>> > >> >> > > >> >> > > > > > > > > > 6). And small remarks:
>> > >>> > >> >> > > >> >> > > > > > > > > > +jint
>> vm_init1(JavaVM_Internal *
>> > >>> > >> java_vm,
>> > >>> > >> >> > > >> >> JavaVMInitArgs * vm_arguments);
>> > >>> > >> >> > > >> >> > > > > > > > > > +jint
>> vm_init2(JNIEnv_Internal *
>> > >>> > >> >> jni_env);
>> > >>> > >> >> > > >> >> > > > > > > > > > Could you make names more
>> > >>> meaningful,
>> > >>> > >> >> then 1,2,3...?
>> > >>> > >> >> > > >> >> > > > > > > > > Ok, will do that.
>> > >>> > >> >> > > >> >> > > > > > > > >
>> > >>> > >> >> > > >> >> > > > > > > > > >
>> > >>> > >> >> > > >> >> > > > > > > > > > class VM_thread {
>> > >>> > >> >> > > >> >> > > > > > > > > > ...
>> > >>> > >> >> > > >> >> > > > > > > > > > + JNIEnv_Internal * jni_env;
>> > >>> > >> >> > > >> >> > > > > > > > > > The jthread already has the
>> jni_env
>> > >>> > >> >> pointer, you do
>> > >>> > >> >> > > >> >> not need to
>> > >>> > >> >> > > >> >> > > > > > > > > > duplicate it here.
>> > >>> > >> >> > > >> >> > > > > > > > > > forexample by using
>> > >>> > >> >> > > >> >> jthread_get_JNI_env(jthread_self());
>> > >>> > >> >> > > >> >> > > > > > > > >
>> > >>> > >> >> > > >> >> > > > > > > > > Yes I know. I don't see any
>> problems
>> > >>> > >> >> here. Some times
>> > >>> > >> >> > > >> >> it is much more
>> > >>> > >> >> > > >> >> > > > > > > > > convenient to get JNIEnv from
>> > >>> VM_thread
>> > >>> > >> >> structure (and
>> > >>> > >> >> > > >> >> faster) instead
>> > >>> > >> >> > > >> >> > > > > > > > > of doing jthread_get_JNI_env
>> > >>> > >> (jthread_self
>> > >>> > >> >> ()). So I
>> > >>> > >> >> > > >> >> need strong
>> > >>> > >> >> > > >> >> > > > > > > > > arguments for removing it.
>> Again it
>> > >>> > >> >> seems that should
>> > >>> > >> >> > > >> >> be addressed in
>> > >>> > >> >> > > >> >> > > > > > > > > design of multi VM. So lets
>> forget
>> > >>> about
>> > >>> > >> >> it for a
>> > >>> > >> >> > > >> >> while...
>> > >>> > >> >> > > >> >> > > > > > > >
>> > >>> > >> >> > > >> >> > > > > > > > I think that the data
>> duplication would
>> > >>> > >> >> always serve as
>> > >>> > >> >> > > >> >> a potential
>> > >>> > >> >> > > >> >> > > > > > > > source of errors - while
>> updating one
>> > >>> copy
>> > >>> > >> >> of object,
>> > >>> > >> >> > > >> >> you may forget
>> > >>> > >> >> > > >> >> > > > > > > > to update the other, often
>> resulting
>> > >>> into
>> > >>> > >> >> a strange
>> > >>> > >> >> > > >> >> behavior of the
>> > >>> > >> >> > > >> >> > > > > > > > whole application. Let's see
>> what are
>> > >>> the
>> > >>> > >> >> specific
>> > >>> > >> >> > > >> >> performance
>> > >>> > >> >> > > >> >> > > > > > > > concerns that have to be addressed.
>> > >>> To get
>> > >>> > >> >> VM_thread
>> > >>> > >> >> > > >> >> structure, you
>> > >>> > >> >> > > >> >> > > > > > > > would eventually go to the TLS,
>> just
>> > >>> like
>> > >>> > >> >> > > >> >> > > > > > > > jthread_get_JNI_env(jthread_self()
>> > >>> > >> would do.
>> > >>> > >> >> > > >> >> > > > > > > If there is already VM_thread
>> structure
>> > >>> for
>> > >>> > >> >> some reasons
>> > >>> > >> >> > > >> >> then there
>> > >>> > >> >> > > >> >> > > > > > > will be no extra access to TLS. It is
>> > >>> > >> >> definitely much
>> > >>> > >> >> > > >> more in
>> > >>> > >> >> > > >> >> > > > > > > jthread_get_JNI_env(jthread_self()
>> than
>> > >>> just
>> > >>> > >> >> one TLS
>> > >>> > >> >> > > >> >> access and one
>> > >>> > >> >> > > >> >> > > > > > > dereferncing. I don't think it is
>> a really
>> > >>> > >> >> big problem
>> > >>> > >> >> > > >> >> now. Do you
>> > >>> > >> >> > > >> >> > > > > > > agree to look at this later. I guess
>> > >>> > >> multi VM
>> > >>> > >> >> > > >> >> implementation will
>> > >>> > >> >> > > >> >> > > > > > > alter it in any case.
>> > >>> > >> >> > > >> >> > > > > > >
>> > >>> > >> >> > > >> >> > > > > > > Thanks
>> > >>> > >> >> > > >> >> > > > > > > Evgueni
>> > >>> > >> >> > > >> >> > > > > > >
>> > >>> > >> >> > > >> >> > > > > > > >
>> > >>> > >> >> > > >> >> > > > > > > > Thanks,
>> > >>> > >> >> > > >> >> > > > > > > > Andrey.
>> > >>> > >> >> > > >> >> > > > > > > >
>> > >>> > >> >> > > >> >> > > > > > > > >
>> > >>> > >> >> > > >> >> > > > > > > > > Evgueni
>> > >>> > >> >> > > >> >> > > > > > > > > >
>> > >>> > >> >> > > >> >> > > > > > > > > > Thanks
>> > >>> > >> >> > > >> >> > > > > > > > > > Artem
>> > >>> > >> >> > > >> >> > > > > > > > > >
>> > >>> > >> >> > > >> >> > > > > > > > > > On 9/28/06, Evgueni Brevnov
>> > >>> > >> >> > > >> >> <ev...@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.
>> > >>> > >> >> > > >> >> > > > > > > > > > >
>> > >>> > >> >> > > >> >> > > > > > > > > > > Thanks
>> > >>> > >> >> > > >> >> > > > > > > > > > > Evgueni
>> > >>> > >> >> > > >> >> > > > > > > > > > >
>> > >>> > >> >> > > >> >> > > > > > > > > > > On 9/28/06, Geir Magnusson
>> Jr.
>> > >>> > >> >> <ge...@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
>> > >>> > >> >> > > >> >> <we...@gmail.com> wrote:
>> > >>> > >> >> > > >> >> > > > > > > > > > > > >> On 9/26/06, Evgueni
>> Brevnov
>> > >>> > >> >> > > >> >> <ev...@gmail.com> wrote:
>> > >>> > >> >> > > >> >> > > > > > > > > > > > >> >
>> > >>> > >> >> > > >> >> > > > > > > > > > > > >> > On 9/27/06, Andrey
>> > >>> Chernyshev
>> > >>> > >> >> > > >> >> <a....@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
>> > >>> > >> >> > > >> >> > > > > > > > > > >
>> > >>> > >> >> > > >> >> > > > > > > > > > >
>> > >>> > >> >> > > >> >> > > > > > > > > >
>> > >>> > >> >> > > >> >> > > > > > > > > >
>> > >>> > >> >> > > >> >>
>> > >>> > >> >>
>> > >>> > >>
>> > >>>
>> ---------------------------------------------------------------------
>> > >>> > >> >> > > >> >> > > > > > > > > > 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
>> > >>> > >> >> > > >> >> > > > > > > > >
>> > >>> > >> >> > > >> >> > > > > > > > >
>> > >>> > >> >> > > >> >> > > > > > > >
>> > >>> > >> >> > > >> >> > > > > > > >
>> > >>> > >> >> > > >> >> > > > > > > > --
>> > >>> > >> >> > > >> >> > > > > > > > Andrey Chernyshev
>> > >>> > >> >> > > >> >> > > > > > > > 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
>> > >>> > >> >> > > >> >> > > > > >
>> > >>> > >> >> > > >> >> > > > > >
>> > >>> > >> >> > > >> >> > > > >
>> > >>> > >> >> > > >> >> > > > >
>> > >>> > >> >> > > >> >> > > > > --
>> > >>> > >> >> > > >> >> > > > > Andrey Chernyshev
>> > >>> > >> >> > > >> >> > > > > 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
>> > >>> > >> >> > > >> >> > > >
>> > >>> > >> >> > > >> >> > > >
>> > >>> > >> >> > > >> >> > >
>> > >>> > >> >> > > >> >> > >
>> > >>> > >> >> > > >> >> > > --
>> > >>> > >> >> > > >> >> > > Andrey Chernyshev
>> > >>> > >> >> > > >> >> > > 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
>> > >>> > >> >> > > >>
>> > >>> > >> >> > > >>
>> > >>> > >> >> > > >
>> > >>> > >> >> > > >
>> > >>> > >> >>
>> > >>> > >>
>> > >>>
>> ---------------------------------------------------------------------
>> > >>> > >> >> > > > 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
>> > >>> > >> >
>> > >>> > >>
>> > >>> > >>
>> > >>> > >>
>> > >>>
>> ---------------------------------------------------------------------
>> > >>> > >> 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
>> > >>> >
>> > >>> >
>> > >>>
>> > >>
>> > >>
>> ---------------------------------------------------------------------
>> > >> 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
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> 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
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
Posted by Alexey Varlamov <al...@gmail.com>.
Hurray! We did it at last! Congratulations :)
2006/10/9, Evgueni Brevnov <ev...@gmail.com>:
> Ok, I go home. I have peace in my mind now :-)
>
> Thank you all
> Evgueni
>
> On 10/9/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> > ok - I just passed a smoke test, gc.PhantomReferenceQueueTest, that was
> > failing. We should look at that and see why it's so flakey.
> >
> > If this works, I'm going to commit this thing so we can move forward.
> >
> > We should focus on stablizing the c-unit tests, btw...
> >
> > geir
> >
> >
> > Geir Magnusson Jr. wrote:
> > >
> > >
> > > Evgueni Brevnov wrote:
> > >> Geir, Salikh,
> > >>
> > >> cunit tests are very unstable...... that's why we have different
> > >> results on different platforms. It all tests problems. I already fixed
> > >> several places but it seems there is much more left. I believe we need
> > >> to revise them all. The main problem is that sleep(somthing) is used
> > >> to synchronize different threads. Sometimes there is no synchraniztion
> > >> at all. I propouse for switching it off until they get stable.
> > >> Can we do it?
> > >
> > > No. They all pass for me now, and I think that they are important as
> > > they are better than nothing.
> > >
> > > I suspected that these were just timing issues - we should just hunker
> > > down and get them fixed ASAP. We're making progress
> > >
> > > geir
> > >
> > >>
> > >> Evgueni
> > >>
> > >> On 10/9/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> > >>> Could you insert sleep_a_click(); just before line 59 right after
> > >>> hysem_create(&start, 0, 1):
> > >>>
> > >>> Does it help?
> > >>>
> > >>> On 10/9/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> > >>> > [echo] ## Executing C unit test: test_ti_instrum
> > >>> > [exec] Result: 1
> > >>> > [echo] INFO: TEST test_jthread_get_all_threads start
> > >>> > [echo] ERROR: Assertion '(thread_count)==(i +
> > >>> > initial_thread_count)' failed at /home/geir/dev/apache/harmony/
> > >>> > enhanced/trunk/working_vm/vm/tes
> > >>> > ts/unit/thread/test_ti_instrum.c:94
> > >>> > [echo] Init1: initial_thread_count=1, initial_all_threads_count=1
> > >>> > [echo] Init3: initial_thread_count=1, initial_all_threads_count=1
> > >>> > [echo] Init3: thread_count=3, all_threads_count=3
> > >>> > [echo] INFO: TEST test_jthread_get_all_threads: FAILED
> > >>> > [echo] INFO: TEST test_jthread_get_thread_count start
> > >>> > [echo] Init1: initial_thread_count=3, initial_all_threads_count=3
> > >>> > [echo] INFO: TEST test_jthread_get_thread_count: PASSED
> > >>> > [echo] INFO: TEST test_jthread_get_blocked_count start
> > >>> > [echo] INFO: TEST test_jthread_get_blocked_count: PASSED
> > >>> > [echo] ## TEST FAILED
> > >>> >
> > >>> >
> > >>> > On Oct 9, 2006, at 12:35 AM, Evgueni Brevnov wrote:
> > >>> >
> > >>> > > I put debug printing into test_ti_instrum.c and attached it to JIRA.
> > >>> > > Could you run it on your machine and send me console output.
> > >>> > >
> > >>> > > Evgueni
> > >>> > >
> > >>> > > On 10/9/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> > >>> > >> I keep getting a failure when running the tests -
> > >>> > >>
> > >>> > >> test_jthread_get_all-threads failling the assertion at
> > >>> > >> test_ti_instrum.c:80
> > >>> > >>
> > >>> > >> geir
> > >>> > >>
> > >>> > >> On Oct 8, 2006, at 7:19 AM, Evgueni Brevnov wrote:
> > >>> > >>
> > >>> > >> > While running cunit on Linux it turned out one test case fails
> > >>> some
> > >>> > >> > time. The fix is in tests.final.2.patch.
> > >>> > >> >
> > >>> > >> > So the last versions to be committed:
> > >>> > >> > invocation_api.final.patch
> > >>> > >> > build.final.2.patch
> > >>> > >> > tests.final.2.patch
> > >>> > >> >
> > >>> > >> > Evgueni
> > >>> > >> >
> > >>> > >> >
> > >>> > >> > On 10/8/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> > >>> > >> >> I mahaged to resolve the problem on Linux.... will update
> > >>> > >> >> build.final.patch with build.final.2.patch in a while
> > >>> > >> >>
> > >>> > >> >> On 10/8/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> > >>> > >> >> > Hi,
> > >>> > >> >> >
> > >>> > >> >> > Oh! Ooh! I did that..... I passed cunit, somke, kernel
> > >>> tests on
> > >>> > >> >> > Windows and smoke, kernel tests on Linux. Unfortunately I
> > >>> > >> failed to
> > >>> > >> >> > link cunit tests on Linux so far. So I disabled cunit on Linux
> > >>> > >> >> until
> > >>> > >> >> > the problem is solved. I believe it is acceptable as short
> > >>> term
> > >>> > >> >> > solution. I found several problems in cunit tests. I will come
> > >>> > >> >> up with
> > >>> > >> >> > my findings later (not today).
> > >>> > >> >> >
> > >>> > >> >> > Use latest patches from HARMONY-1582. They are marked as
> > >>> final.
> > >>> > >> >> There
> > >>> > >> >> > are three patches. One for build module, one for cunit
> > >>> tests and
> > >>> > >> >> one
> > >>> > >> >> > for VM itself.
> > >>> > >> >> >
> > >>> > >> >> > Thanks
> > >>> > >> >> > Evgueni
> > >>> > >> >> >
> > >>> > >> >> >
> > >>> > >> >> > On 10/6/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> > >>> > >> >> > > Nooooooo! LOL
> > >>> > >> >> > >
> > >>> > >> >> > > I'm here waiting - This will unblock a whole bunch of
> > >>> > >> things :)
> > >>> > >> >> > >
> > >>> > >> >> > > Thanks for the effort
> > >>> > >> >> > >
> > >>> > >> >> > > Evgueni Brevnov wrote:
> > >>> > >> >> > > > Geir,
> > >>> > >> >> > > >
> > >>> > >> >> > > > That's terrible. We have power outage....servers are
> > >>> down. I
> > >>> > >> >> can't
> > >>> > >> >> > > > send the patches now.... will do it tomorrow
> > >>> > >> >> > > >
> > >>> > >> >> > > > Evgueni
> > >>> > >> >> > > > On 10/5/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> > >>> > >> >> > > >> woo hoo! here we go...
> > >>> > >> >> > > >>
> > >>> > >> >> > > >>
> > >>> > >> >> > > >> Andrey Chernyshev wrote:
> > >>> > >> >> > > >> > Hi Evgueni,
> > >>> > >> >> > > >> >
> > >>> > >> >> > > >> > On 10/4/06, Evgueni Brevnov <ev...@gmail.com>
> > >>> > >> >> wrote:
> > >>> > >> >> > > >> >> Hi All,
> > >>> > >> >> > > >> >>
> > >>> > >> >> > > >> >> I have attached updated patch to the JIRA. It should
> > >>> > >> >> resolve remain
> > >>> > >> >> > > >> >> concerns. Andrey, could you give a green light now?
> > >>> > >> >> > > >> >
> > >>> > >> >> > > >> > Thanks for updating the patch! I agree it it can be
> > >>> > >> >> committed, at
> > >>> > >> >> > > >> > least signatures look good. 5 revisions seem like more
> > >>> > >> >> than enough :).
> > >>> > >> >> > > >> > Anyways, I think the remaining issues can be resolved
> > >>> > >> >> with additional
> > >>> > >> >> > > >> > patches. Thanks again for the good work and your
> > >>> > >> patience.
> > >>> > >> >> > > >> >
> > >>> > >> >> > > >> > Thanks,
> > >>> > >> >> > > >> > Andrey.
> > >>> > >> >> > > >> >
> > >>> > >> >> > > >> >>
> > >>> > >> >> > > >> >> Thanks
> > >>> > >> >> > > >> >> Evgueni
> > >>> > >> >> > > >> >>
> > >>> > >> >> > > >> >> On 10/4/06, Evgueni Brevnov
> > >>> <ev...@gmail.com>
> > >>> > >> >> wrote:
> > >>> > >> >> > > >> >> > Andrey,
> > >>> > >> >> > > >> >> >
> > >>> > >> >> > > >> >> > I see your points. I think both approaches have
> > >>> > >> >> advantages and
> > >>> > >> >> > > >> >> > disadvantages. I think it is quite hard to say which
> > >>> > >> >> approach is
> > >>> > >> >> > > >> >> > better until we play with one VM only. I still feel
> > >>> > >> >> like introducing
> > >>> > >> >> > > >> >> > one more dependence is better than spreading code
> > >>> > >> >> which deals with
> > >>> > >> >> > > >> >> > attachment among VM and TM. We really get stuck. OK,
> > >>> > >> >> just because I
> > >>> > >> >> > > >> >> > want to move forward I will do required changes to
> > >>> > >> remove
> > >>> > >> >> > > >> >> > vm_create_jthread from TM. I believe that will
> > >>> resolve
> > >>> > >> >> all our
> > >>> > >> >> > > >> >> > disagreements and the patch will be applied soon.
> > >>> > >> >> > > >> >> >
> > >>> > >> >> > > >> >> >
> > >>> > >> >> > > >> >> > Thanks
> > >>> > >> >> > > >> >> > Evgueni.
> > >>> > >> >> > > >> >> >
> > >>> > >> >> > > >> >> > On 10/4/06, Andrey Chernyshev
> > >>> > >> >> <a....@gmail.com> wrote:
> > >>> > >> >> > > >> >> > > On 10/3/06, Evgueni Brevnov
> > >>> > >> >> <ev...@gmail.com> wrote:
> > >>> > >> >> > > >> >> > > > On 10/3/06, Andrey Chernyshev
> > >>> > >> >> <a....@gmail.com> wrote:
> > >>> > >> >> > > >> >> > > > > On 10/2/06, Evgueni Brevnov
> > >>> > >> >> <ev...@gmail.com> wrote:
> > >>> > >> >> > > >> >> > > > > > Andrey,
> > >>> > >> >> > > >> >> > > > > >
> > >>> > >> >> > > >> >> > > > > > Just to be clear.... I agree with you it is
> > >>> > >> more
> > >>> > >> >> > > >> convenient if
> > >>> > >> >> > > >> >> > > > > > jthread_create takes JNIEnv instead of
> > >>> > >> JavaVM. It
> > >>> > >> >> > > >> reflects that
> > >>> > >> >> > > >> >> > > > > > current thread has been attached already. Do
> > >>> > >> >> you think it
> > >>> > >> >> > > >> >> makes sense
> > >>> > >> >> > > >> >> > > > > > to get rid of JNIEnv and use
> > >>> > >> >> jthread_get_JNI_env in that
> > >>> > >> >> > > >> case?
> > >>> > >> >> > > >> >> > > > >
> > >>> > >> >> > > >> >> > > > > The jthread_* layer is designed like if it
> > >>> were
> > >>> > >> >> a regular JNI
> > >>> > >> >> > > >> >> > > > > application which is meant to be called
> > >>> from the
> > >>> > >> >> Java code,
> > >>> > >> >> > > >> hence
> > >>> > >> >> > > >> >> > > > > every function on that layer receives
> > >>> JNIenv. We
> > >>> > >> >> can probably
> > >>> > >> >> > > >> >> get rid
> > >>> > >> >> > > >> >> > > > > of the JNEnv parameter for jthread_*
> > >>> functions,
> > >>> > >> >> assuming that
> > >>> > >> >> > > >> >> TM can
> > >>> > >> >> > > >> >> > > > > always extract JNIenv for the current thread
> > >>> > >> with
> > >>> > >> >> > > >> >> > > > > jthread_get_JNI_env().
> > >>> > >> >> > > >> >> > > > > My only concern would be the performance -
> > >>> once
> > >>> > >> >> the JNIenv is
> > >>> > >> >> > > >> >> already
> > >>> > >> >> > > >> >> > > > > known for the native part of the kernel
> > >>> classes
> > >>> > >> >> impl, it
> > >>> > >> >> > > >> must be
> > >>> > >> >> > > >> >> > > > > cheaper to pass JNIEnv to TM as an extra
> > >>> > >> >> parameter rather than
> > >>> > >> >> > > >> >> extract
> > >>> > >> >> > > >> >> > > > > it from the TLS again.
> > >>> > >> >> > > >> >> > > > > Other than that, I see no strong advantages in
> > >>> > >> >> keeping JNIEnv
> > >>> > >> >> > > >> >> parameter.
> > >>> > >> >> > > >> >> > > > >
> > >>> > >> >> > > >> >> > > > >
> > >>> > >> >> > > >> >> > > > > > Regarding jthread_attach. I still didn't get
> > >>> > >> >> your point....
> > >>> > >> >> > > >> >> Clarify it
> > >>> > >> >> > > >> >> > > > > > please if you think jhread_attach should be
> > >>> > >> >> modified.
> > >>> > >> >> > > >> >> > > > >
> > >>> > >> >> > > >> >> > > > > Sorry for being not clear: I think for
> > >>> > >> >> jthread_attach, we have
> > >>> > >> >> > > >> >> two options:
> > >>> > >> >> > > >> >> > > > > 1) Make JNIEnv input parameter - it must be
> > >>> new
> > >>> > >> >> JNIEnv that VM
> > >>> > >> >> > > >> >> > > > > pre-allocates for the new Java thread.
> > >>> > >> >> jthread_attach
> > >>> > >> >> > > >> would just
> > >>> > >> >> > > >> >> > > > > associate it with the current thread.
> > >>> > >> >> > > >> >> > > > >
> > >>> > >> >> > > >> >> > > > > 2) Obtain JNIEnv via vm_attach() callback. In
> > >>> > >> >> this case, if
> > >>> > >> >> > > >> >> > > > > vm_attach() callback implementation needs to
> > >>> > >> >> know for which
> > >>> > >> >> > > >> >> JavaVM new
> > >>> > >> >> > > >> >> > > > > JNIenv has to be allocated, then we'll need to
> > >>> > >> >> add JavaVM as
> > >>> > >> >> > > >> >> input
> > >>> > >> >> > > >> >> > > > > parameter for jthread_attach().
> > >>> > >> >> > > >> >> > > > > I think both options should be fine, (1) would
> > >>> > >> >> probably
> > >>> > >> >> > > >> keep TM
> > >>> > >> >> > > >> >> > > > > interface a bit lighter, though (2) may look
> > >>> > >> >> more closer to
> > >>> > >> >> > > >> >> the JNI
> > >>> > >> >> > > >> >> > > > > invocation API idea.
> > >>> > >> >> > > >> >> > > > > So I think adding JavaVM specifically for
> > >>> > >> >> jthread_attach
> > >>> > >> >> > > >> may make
> > >>> > >> >> > > >> >> > > > > sense given the explanation you provided
> > >>> > >> earlier.
> > >>> > >> >> > > >> >> > > > >
> > >>> > >> >> > > >> >> > > > > The concern I would have regarding the
> > >>> proposed
> > >>> > >> >> jthread_attach
> > >>> > >> >> > > >> >> > > > > implementation is a call to
> > >>> vm_create_jthread()
> > >>> > >> >> - this call
> > >>> > >> >> > > >> >> introduces
> > >>> > >> >> > > >> >> > > > > an extra dependency of TM on vmcore that I'd
> > >>> > >> >> prefer to be
> > >>> > >> >> > > >> >> avoided. In
> > >>> > >> >> > > >> >> > > > > the original version, jthread_attach() was
> > >>> > >> >> taking jthread
> > >>> > >> >> > > >> >> argument of
> > >>> > >> >> > > >> >> > > > > the already prepared j.l.Thread.
> > >>> > >> >> > > >> >> > > >
> > >>> > >> >> > > >> >> > > > I understand your concern. Unfortunately I don't
> > >>> > >> >> see what we
> > >>> > >> >> > > >> can do
> > >>> > >> >> > > >> >> > > > here. Let me explain. In the beginning you
> > >>> have an
> > >>> > >> >> unattached
> > >>> > >> >> > > >> >> native
> > >>> > >> >> > > >> >> > > > thread. To be able to call java code (which is
> > >>> > >> >> required for
> > >>> > >> >> > > >> >> > > > constructing j.l.Thread instance) the thread
> > >>> > >> >> should be attached
> > >>> > >> >> > > >> >> first.
> > >>> > >> >> > > >> >> > > > To be specific it should be attached to VM by
> > >>> > >> >> calling vm_attach
> > >>> > >> >> > > >> >> which
> > >>> > >> >> > > >> >> > > > will return a valid JNIEnv It is valid to use
> > >>> JNI
> > >>> > >> >> from that
> > >>> > >> >> > > >> moment.
> > >>> > >> >> > > >> >> > > > Obtained JNIEnv can be used to execute java code
> > >>> > >> >> and create
> > >>> > >> >> > > >> >> j.l.Thread
> > >>> > >> >> > > >> >> > > > instance. Since we do vm_attach in
> > >>> jthread_attach
> > >>> > >> >> we need to do
> > >>> > >> >> > > >> >> > > > vm_create_jthread inside jthread_atach as well.
> > >>> > >> >> > > >> >> > > > Of course it can be an alternative to do
> > >>> vm_attach
> > >>> > >> >> and
> > >>> > >> >> > > >> >> > > > vm_create_jthread outside of TM right before
> > >>> > >> >> jthread_attach.
> > >>> > >> >> > > >> >> Sure it
> > >>> > >> >> > > >> >> > > > will reduce one dependence between VM and TM.
> > >>> But
> > >>> > >> >> it seems like
> > >>> > >> >> > > >> >> > > > artificial action for me just because of
> > >>> > >> >> dependency....
> > >>> > >> >> > > >> >> > >
> > >>> > >> >> > > >> >> > > Why do you think it is artificial? I would rather
> > >>> > >> >> prefer not to
> > >>> > >> >> > > >> throw
> > >>> > >> >> > > >> >> > > vm_attach event from the jthread_attach() call at
> > >>> > >> >> all than to add
> > >>> > >> >> > > >> >> > > extra dependency. The idea of jthread layer is a
> > >>> > >> >> Java face to
> > >>> > >> >> > > >> >> > > hythread, it is meant to know either a little or
> > >>> > >> >> nothing about the
> > >>> > >> >> > > >> >> > > rest of VM. It may be logical to throw vm_attach
> > >>> > >> >> call from the
> > >>> > >> >> > > >> newly
> > >>> > >> >> > > >> >> > > created thread, because there is no other way
> > >>> to let
> > >>> > >> >> know VM
> > >>> > >> >> > > >> the new
> > >>> > >> >> > > >> >> > > thread is created. VM attach is a different case -
> > >>> > >> >> VM already
> > >>> > >> >> > > >> knows
> > >>> > >> >> > > >> >> > > about new Java thread at the time of the
> > >>> > >> >> AttachCurrentThread call.
> > >>> > >> >> > > >> >> > >
> > >>> > >> >> > > >> >> > > >
> > >>> > >> >> > > >> >> > > > > Do you think it makes sense to replace a
> > >>> single
> > >>> > >> >> jthread
> > >>> > >> >> > > >> >> parameter with
> > >>> > >> >> > > >> >> > > > > a variety of stuff (like thread group,
> > >>> name)? It
> > >>> > >> >> seems the
> > >>> > >> >> > > >> only
> > >>> > >> >> > > >> >> > > > > purpose of at these args is to be passed
> > >>> back to
> > >>> > >> >> VM for
> > >>> > >> >> > > >> >> > > > > vm_jthread_create(). I would suggest to change
> > >>> > >> >> this and try
> > >>> > >> >> > > >> doing
> > >>> > >> >> > > >> >> > > > > either of:
> > >>> > >> >> > > >> >> > > > > 1) Make signature of jthread_attach with 3
> > >>> args,
> > >>> > >> >> JavaVM,
> > >>> > >> >> > > >> >> jthread and the daemon.
> > >>> > >> >> > > >> >> > > > Why do you want to pass daemon to TM but
> > >>> thread's
> > >>> > >> >> name and
> > >>> > >> >> > > >> >> group. Just
> > >>> > >> >> > > >> >> > > > because current TM doesn't need such
> > >>> information?
> > >>> > >> >> What if it is
> > >>> > >> >> > > >> >> > > > required to get thread name later? Say by
> > >>> > >> introducing
> > >>> > >> >> > > >> >> > >
> > >>> > >> >> > > >> >> > > I imagine you need a daemon attribute since the TM
> > >>> > >> >> is still
> > >>> > >> >> > > >> managing
> > >>> > >> >> > > >> >> > > the thread daemonality. TM is not managing thread
> > >>> > >> >> name and group -
> > >>> > >> >> > > >> >> > > they are all kept on the Java level, hence passing
> > >>> > >> >> them may be
> > >>> > >> >> > > >> >> > > excessive.
> > >>> > >> >> > > >> >> > >
> > >>> > >> >> > > >> >> > > > jthread_get_name... What will you do in that
> > >>> case?
> > >>> > >> >> Let me
> > >>> > >> >> > > >> guess you
> > >>> > >> >> > > >> >> > > > will call j.l.Thread.getName. Right. Ok! In that
> > >>> > >> >> case I see no
> > >>> > >> >> > > >> >> > > > problems to call j.l.Thread.isDaemon. Do you
> > >>> > >> >> agree? So it
> > >>> > >> >> > > >> doesn't
> > >>> > >> >> > > >> >> > >
> > >>> > >> >> > > >> >> > > As I suggested earlier, the best way to handle
> > >>> > >> >> daemonality would
> > >>> > >> >> > > >> >> > > probably be in pure Java - in j.l.Thread (or
> > >>> > >> >> > > >> j.l.VMThreadManager) or
> > >>> > >> >> > > >> >> > > whatever. You already lifted it up to the jthread
> > >>> > >> >> level, but
> > >>> > >> >> > > >> what if
> > >>> > >> >> > > >> >> > > we can go a little bit higher...
> > >>> > >> >> > > >> >> > >
> > >>> > >> >> > > >> >> > > > seems to be a good design to pass only part
> > >>> of the
> > >>> > >> >> > > >> information to
> > >>> > >> >> > > >> >> > > > jthread_atach. Lets look at the signature of
> > >>> > >> >> > > >> >> AttachCurrentThread. It
> > >>> > >> >> > > >> >> > > > takes exactly these three parameters (daemon,
> > >>> > >> >> name, group)
> > >>> > >> >> > > >> >> passed as a
> > >>> > >> >> > > >> >> > > > structure. I was thinking about having
> > >>> exactly the
> > >>> > >> >> same
> > >>> > >> >> > > >> >> structure as
> > >>> > >> >> > > >> >> > > > third parameter of jthread_attach but it occured
> > >>> > >> >> to be more
> > >>> > >> >> > > >> >> convinient
> > >>> > >> >> > > >> >> > > > to pass them seperatly. Although I don't see
> > >>> > >> >> strong reasons
> > >>> > >> >> > > >> against
> > >>> > >> >> > > >> >> > > > having a structure a third parameter.
> > >>> > >> >> > > >> >> > >
> > >>> > >> >> > > >> >> > > I see. Acually, I would love to keep the
> > >>> > >> >> jthread_attach func-ty at
> > >>> > >> >> > > >> >> the
> > >>> > >> >> > > >> >> > > minimum level which will be needed to handle the
> > >>> > >> >> only data that TM
> > >>> > >> >> > > >> >> > > should be aware of. We need a formal boundary
> > >>> > >> >> between jthread
> > >>> > >> >> > > >> layer
> > >>> > >> >> > > >> >> > > and vmcore (otherwise jthread won't have a much of
> > >>> > >> >> sense, one may
> > >>> > >> >> > > >> >> > > consider it just as a convenience set of functions
> > >>> > >> >> in vmcore which
> > >>> > >> >> > > >> >> are
> > >>> > >> >> > > >> >> > > doing something with threading).
> > >>> > >> >> > > >> >> > >
> > >>> > >> >> > > >> >> > > >
> > >>> > >> >> > > >> >> > > > > 2) Move the implementation of
> > >>> vm_create_jtrhead
> > >>> > >> >> () to
> > >>> > >> >> > > >> >> > > > > thread_java_basic.c - could it be written in
> > >>> > >> >> pure JNI without
> > >>> > >> >> > > >> >> using
> > >>> > >> >> > > >> >> > > > > internal VM API like class_alloc_new_object()?
> > >>> > >> >> > > >> >> > > >
> > >>> > >> >> > > >> >> > > > Yes, this can be done but it doesn't fix the
> > >>> > >> >> problem. You still
> > >>> > >> >> > > >> >> need
> > >>> > >> >> > > >> >> > > > to know about internal constructor of j.l.Thread
> > >>> > >> >> > > >> >> > >
> > >>> > >> >> > > >> >> > > That's bad. Given what you said, now it seems that
> > >>> > >> >> the most
> > >>> > >> >> > > >> >> preferable
> > >>> > >> >> > > >> >> > > sequence for AttachCurrentThread impl still
> > >>> would be
> > >>> > >> >> like:
> > >>> > >> >> > > >> >> > > JNIEnv = vm_attach();
> > >>> > >> >> > > >> >> > > jthread = create_jthread(JNIenv)
> > >>> > >> >> > > >> >> > > jthread_attach(JNIEnv, jthread) // stores
> > >>> JNIEnv and
> > >>> > >> >> Hythread into
> > >>> > >> >> > > >> >> > > TLS, doesn't call vm_attach any longer.
> > >>> > >> >> > > >> >> > > - this is almost what we had from the beginning...
> > >>> > >> >> > > >> >> > >
> > >>> > >> >> > > >> >> > > Thanks,
> > >>> > >> >> > > >> >> > > Andrey.
> > >>> > >> >> > > >> >> > >
> > >>> > >> >> > > >> >> > > >
> > >>> > >> >> > > >> >> > > >
> > >>> > >> >> > > >> >> > > > Thanks
> > >>> > >> >> > > >> >> > > > Evgueni
> > >>> > >> >> > > >> >> > > > >
> > >>> > >> >> > > >> >> > > > >
> > >>> > >> >> > > >> >> > > > > Thanks,
> > >>> > >> >> > > >> >> > > > > Andrey.
> > >>> > >> >> > > >> >> > > > >
> > >>> > >> >> > > >> >> > > > > >
> > >>> > >> >> > > >> >> > > > > > Thank you
> > >>> > >> >> > > >> >> > > > > > Evgueni
> > >>> > >> >> > > >> >> > > > > >
> > >>> > >> >> > > >> >> > > > > > On 10/2/06, Evgueni Brevnov
> > >>> > >> >> <ev...@gmail.com>
> > >>> > >> >> > > >> wrote:
> > >>> > >> >> > > >> >> > > > > > > On 9/29/06, Andrey Chernyshev
> > >>> > >> >> <a....@gmail.com>
> > >>> > >> >> > > >> >> wrote:
> > >>> > >> >> > > >> >> > > > > > > > On 9/29/06, Evgueni Brevnov
> > >>> > >> >> <ev...@gmail.com>
> > >>> > >> >> > > >> >> wrote:
> > >>> > >> >> > > >> >> > > > > > > > > Artem,
> > >>> > >> >> > > >> >> > > > > > > > >
> > >>> > >> >> > > >> >> > > > > > > > > Thank you for your feedback....
> > >>> find my
> > >>> > >> >> inlined.....
> > >>> > >> >> > > >> >> > > > > > > > >
> > >>> > >> >> > > >> >> > > > > > > > > On 9/29/06, Artem Aliev
> > >>> > >> >> <ar...@gmail.com> wrote:
> > >>> > >> >> > > >> >> > > > > > > > > > Evgueni,
> > >>> > >> >> > > >> >> > > > > > > > > >
> > >>> > >> >> > > >> >> > > > > > > > > > I got most of your changes, but
> > >>> still
> > >>> > >> >> disagree
> > >>> > >> >> > > >> with all
> > >>> > >> >> > > >> >> > > > > > > > > > hythread/jthread interface changes.
> > >>> > >> >> Could leave
> > >>> > >> >> > > >> >> interface unchanged.
> > >>> > >> >> > > >> >> > > > > > > > > > See following possible solutions,
> > >>> that
> > >>> > >> >> could solve
> > >>> > >> >> > > >> >> the same problems
> > >>> > >> >> > > >> >> > > > > > > > > > without interface changes.
> > >>> > >> >> > > >> >> > > > > > > > > >
> > >>> > >> >> > > >> >> > > > > > > > > >
> > >>> > >> >> > > >> >> > > > > > > > > > 1) daemon attribute is a java
> > >>> > >> >> specific. (Andrey
> > >>> > >> >> > > >> >> mentioned this already).
> > >>> > >> >> > > >> >> > > > > > > > > > Could you please move it back. to
> > >>> > >> >> the jthread
> > >>> > >> >> > > >> >> layer. It is better
> > >>> > >> >> > > >> >> > > > > > > > > > to rename
> > >>> > >> >> > > >> >> > > > > > > > > >
> > >>> > >> >> hythread_wait_for_all_nondaemon_threads() to
> > >>> > >> >> > > >> >> > > > > > > > > >
> > >>> > >> jthread_wait_for_all_nondaemon_threads().
> > >>> > >> >> > > >> >> > > > > > > > > Ok, I see no problems to move "daemon"
> > >>> > >> >> to java layer.
> > >>> > >> >> > > >> >> In that case:
> > >>> > >> >> > > >> >> > > > > > > > > 1) I will move
> > >>> > >> >> > > >> >> hythread_wait_for_all_nondaemon_threads() from
> > >>> > >> >> > > >> >> > > > > > > > > thread_init.c to one which implements
> > >>> > >> >> java layer.
> > >>> > >> >> > > >> >> > > > > > > > > 2) I will move daemon field from
> > >>> > >> >> HyThread structure.
> > >>> > >> >> > > >> >> > > > > > > > >
> > >>> > >> >> > > >> >> > > > > > > > > Agree?
> > >>> > >> >> > > >> >> > > > > > > >
> > >>> > >> >> > > >> >> > > > > > > > Sounds good to me.
> > >>> > >> >> > > >> >> > > > > > >
> > >>> > >> >> > > >> >> > > > > > > OK, will do that.
> > >>> > >> >> > > >> >> > > > > > >
> > >>> > >> >> > > >> >> > > > > > > >
> > >>> > >> >> > > >> >> > > > > > > >
> > >>> > >> >> > > >> >> > > > > > > > >
> > >>> > >> >> > > >> >> > > > > > > > > >
> > >>> > >> >> > > >> >> > > > > > > > > > 2) JavaVM could be retrieved from
> > >>> > >> >> JNIEnv by
> > >>> > >> >> > > >> >> jni_get_java_vm(). So
> > >>> > >> >> > > >> >> > > > > > > > > > let the jthread_create() and
> > >>> others to
> > >>> > >> >> use JNIEnv
> > >>> > >> >> > > >> >> (that is passed from
> > >>> > >> >> > > >> >> > > > > > > > > > java native method).
> > >>> > >> >> > > >> >> > > > > > > > > > The vm_attach could get old JNI env
> > >>> > >> >> and create new
> > >>> > >> >> > > >> >> one for the new thread.
> > >>> > >> >> > > >> >> > > > > > > > > > The first JNIEnv is created in
> > >>> > >> >> CreateVM call and
> > >>> > >> >> > > >> >> could be passed to
> > >>> > >> >> > > >> >> > > > > > > > > > the first thread at startup.
> > >>> > >> >> > > >> >> > > > > > > > > No, no, no. I completely disagree with
> > >>> > >> >> that!!! Why do
> > >>> > >> >> > > >> >> you like JNIEnv
> > >>> > >> >> > > >> >> > > > > > > > > but JavaVM. Why do you think that
> > >>> > >> >> passing JavaVM
> > >>> > >> >> > > >> >> instead of JNIEnv
> > >>> > >> >> > > >> >> > > > > > > > > makes TM less modular? I don't see any
> > >>> > >> >> difference
> > >>> > >> >> > > >> >> here.... It seems
> > >>> > >> >> > > >> >> > > > > > > > > for me like a big big hack to grab
> > >>> > >> >> JNIEnv from another
> > >>> > >> >> > > >> >> thread and pass
> > >>> > >> >> > > >> >> > > > > > > > > it to jthread_attach to perform
> > >>> > >> >> operations in the
> > >>> > >> >> > > >> >> current thread.
> > >>> > >> >> > > >> >> > > > > > > >
> > >>> > >> >> > > >> >> > > > > > > > TM needs to know JNIEnv, mainly for
> > >>> > >> >> managing the
> > >>> > >> >> > > >> >> references to
> > >>> > >> >> > > >> >> > > > > > > > objects, throwing exceptions and calling
> > >>> > >> >> run() method of
> > >>> > >> >> > > >> >> a new thread.
> > >>> > >> >> > > >> >> > > > > > > > JNI spec proposes that JNIEnv is valid
> > >>> > >> >> within the given
> > >>> > >> >> > > >> >> thread, this
> > >>> > >> >> > > >> >> > > > > > > > is why TM holds the JNIEnv pointer at
> > >>> the
> > >>> > >> >> moment. This
> > >>> > >> >> > > >> >> is why TM likes
> > >>> > >> >> > > >> >> > > > > > > > the JNIEnv.
> > >>> > >> >> > > >> >> > > > > > > >
> > >>> > >> >> > > >> >> > > > > > > > Having the JNIEnv, one is able to get
> > >>> > >> >> JavaVM but not
> > >>> > >> >> > > >> >> vise versa. This
> > >>> > >> >> > > >> >> > > > > > > > is why TM doesn't like the JavaVM :)
> > >>> > >> >> > > >> >> > > > > > > I see your point. Only one note this is
> > >>> true
> > >>> > >> >> for already
> > >>> > >> >> > > >> >> attached threads...
> > >>> > >> >> > > >> >> > > > > > >
> > >>> > >> >> > > >> >> > > > > > > >
> > >>> > >> >> > > >> >> > > > > > > > I agree with you that there is a design
> > >>> > >> >> flaw that the
> > >>> > >> >> > > >> >> JNIEnv is copied
> > >>> > >> >> > > >> >> > > > > > > > from the parent thread to a child thread
> > >>> > >> >> during thread
> > >>> > >> >> > > >> >> creation. I
> > >>> > >> >> > > >> >> > > > > > > > think it could be resolved via
> > >>> vm_attach()
> > >>> > >> >> hook - with
> > >>> > >> >> > > >> >> this event, VM
> > >>> > >> >> > > >> >> > > > > > > > might tell the TM what the JNIEnv
> > >>> pointer
> > >>> > >> >> for new thread
> > >>> > >> >> > > >> >> should be. I
> > >>> > >> >> > > >> >> > > > > > > > think you did that by extending the
> > >>> > >> >> vm_attach() call
> > >>> > >> >> > > >> >> with the JNIEnv**
> > >>> > >> >> > > >> >> > > > > > > > argument.
> > >>> > >> >> > > >> >> > > > > > > >
> > >>> > >> >> > > >> >> > > > > > > > What is not completely clear is, why do
> > >>> > >> >> you have to pass
> > >>> > >> >> > > >> >> the JavaVM
> > >>> > >> >> > > >> >> > > > > > > > forth and back, once from VM to TM, and
> > >>> > >> >> then back from
> > >>> > >> >> > > >> >> TM to VM again?
> > >>> > >> >> > > >> >> > > > > > > >
> > >>> > >> >> > > >> >> > > > > > > > If you need to know in jthread_attach,
> > >>> > >> >> which particular
> > >>> > >> >> > > >> >> VM vm_attach()
> > >>> > >> >> > > >> >> > > > > > > > event is coming from, you could have
> > >>> > >> >> vm_attach like
> > >>> > >> >> > > >> >> > > > > > > > vm_attach(JNIEnv* currentThreadEnv,
> > >>> > >> JNIEnv**
> > >>> > >> >> > > >> >> newThreadEnv).
> > >>> > >> >> > > >> >> > > > > > > I'm a little bit confused.....Current
> > >>> thread
> > >>> > >> >> hasn't been
> > >>> > >> >> > > >> >> attached yet.
> > >>> > >> >> > > >> >> > > > > > > So there is no JNIEnv for it yet. How
> > >>> it can
> > >>> > >> >> be passed as
> > >>> > >> >> > > >> >> the first
> > >>> > >> >> > > >> >> > > > > > > parameter to vm_attach()?
> > >>> > >> >> > > >> >> > > > > > >
> > >>> > >> >> > > >> >> > > > > > > > Then you will be always able to get the
> > >>> > >> >> JavaVM from the
> > >>> > >> >> > > >> >> JNIEnv.
> > >>> > >> >> > > >> >> > > > > > > > The only difference is that you are
> > >>> > >> >> currently doing
> > >>> > >> >> > > >> >> JNIEnv->JavaVM
> > >>> > >> >> > > >> >> > > > > > > > conversion in the VMThreadManager,
> > >>> but why
> > >>> > >> >> can't you
> > >>> > >> >> > > >> >> just do this in
> > >>> > >> >> > > >> >> > > > > > > > vm_attach() without changing the
> > >>> interface
> > >>> > >> >> of the TM?
> > >>> > >> >> > > >> >> > > > > > > > So far JavaVM really looks like an extra
> > >>> > >> >> knowledge that
> > >>> > >> >> > > >> >> TM doesn't
> > >>> > >> >> > > >> >> > > > > > > > have to be aware of.
> > >>> > >> >> > > >> >> > > > > > > >
> > >>> > >> >> > > >> >> > > > > > > > > Moreover there is no JNIEnv when main
> > >>> > >> >> thread attaches
> > >>> > >> >> > > >> >> to VM. So we
> > >>> > >> >> > > >> >> > > > > > > > > should either keep it as is or change
> > >>> > >> >> original design
> > >>> > >> >> > > >> >> of TM and attach
> > >>> > >> >> > > >> >> > > > > > > > > thread to VM before attaching it to
> > >>> TM.
> > >>> > >> >> In that case
> > >>> > >> >> > > >> >> we will have
> > >>> > >> >> > > >> >> > > > > > > > > valid JNIEnv which can be passed to
> > >>> > >> >> jthread_atatch. We
> > >>> > >> >> > > >> >> need to think
> > >>> > >> >> > > >> >> > > > > > > > > over it twice before changing
> > >>> > >> something....
> > >>> > >> >> > > >> >> > > > > > > >
> > >>> > >> >> > > >> >> > > > > > > > Right. For jthread_attach, JNIenv
> > >>> needs to
> > >>> > >> >> be changed
> > >>> > >> >> > > >> >> from being input
> > >>> > >> >> > > >> >> > > > > > > > parameter to being the output parameter.
> > >>> > >> >> The way how
> > >>> > >> >> > > >> >> JNIenv is
> > >>> > >> >> > > >> >> > > > > > > > obtained by TM should be vm_attach()
> > >>> > >> event.
> > >>> > >> >> > > >> >> > > > > > > OK, JNIEnv is output parameter. And it
> > >>> > >> >> obtained by
> > >>> > >> >> > > >> >> vm_attach(). This
> > >>> > >> >> > > >> >> > > > > > > is exactly like I do in the patch. What I
> > >>> > >> >> don't understand
> > >>> > >> >> > > >> >> is how
> > >>> > >> >> > > >> >> > > > > > > jthread_attach knows to which VM the
> > >>> thread
> > >>> > >> >> should be
> > >>> > >> >> > > >> >> attached? Do you
> > >>> > >> >> > > >> >> > > > > > > suggest calling vm_attach first to create
> > >>> > >> >> JNIEnv it pass
> > >>> > >> >> > > >> >> it to
> > >>> > >> >> > > >> >> > > > > > > jthread_attach?
> > >>> > >> >> > > >> >> > > > > > >
> > >>> > >> >> > > >> >> > > > > > > >
> > >>> > >> >> > > >> >> > > > > > > > >
> > >>> > >> >> > > >> >> > > > > > > > >
> > >>> > >> >> > > >> >> > > > > > > > >
> > >>> > >> >> > > >> >> > > > > > > > > >
> > >>> > >> >> > > >> >> > > > > > > > > >
> > >>> > >> >> > > >> >> > > > > > > > > > 4) Original classlib hythread do
> > >>> > >> not use
> > >>> > >> >> > > >> >> hythread_library_t in arguments,
> > >>> > >> >> > > >> >> > > > > > > > > > It uses following code:
> > >>> > >> >> > > >> >> > > > > > > > > >
> > >>> > >> >> > > >> >> > > > > > > > > > hythread_library_t lib =
> > >>> GLOBAL_DATA
> > >>> > >> >> > > >> >> (default_library);
> > >>> > >> >> > > >> >> > > > > > > > > > or
> > >>> > >> >> > > >> >> > > > > > > > > > hythread_library_t library =
> > >>> thread-
> > >>> > >> >> >library;
> > >>> > >> >> > > >> >> > > > > > > > > >
> > >>> > >> >> > > >> >> > > > > > > > > > So could you please use the same
> > >>> > >> >> mechanism and
> > >>> > >> >> > > >> >> remove hythread_*_ex >functions.
> > >>> > >> >> > > >> >> > > > > > > > > Let's see if classlib's hythread needs
> > >>> > >> >> changing first.
> > >>> > >> >> > > >> >> It seems for me
> > >>> > >> >> > > >> >> > > > > > > > > such code prevents us from having
> > >>> > >> multi VM.
> > >>> > >> >> > > >> >> > > > > > > > >
> > >>> > >> >> > > >> >> > > > > > > > > >
> > >>> > >> >> > > >> >> > > > > > > > > > 5. You introduce more then one jni
> > >>> > >> >> env, but still
> > >>> > >> >> > > >> >> use global variable for it.
> > >>> > >> >> > > >> >> > > > > > > > > > So all changes like following:
> > >>> > >> >> > > >> >> > > > > > > > > > - JNIEnv *jenv = (JNIEnv*)
> > >>> > >> >> jni_native_intf;
> > >>> > >> >> > > >> >> > > > > > > > > > + JNIEnv *jenv = jni_native_intf;
> > >>> > >> >> > > >> >> > > > > > > > > >
> > >>> > >> >> > > >> >> > > > > > > > > > should be like:
> > >>> > >> >> > > >> >> > > > > > > > > > - JNIEnv *jenv = (JNIEnv*)
> > >>> > >> >> jni_native_intf;
> > >>> > >> >> > > >> >> > > > > > > > > > + JNIEnv *jenv = get_jni_env
> > >>> > >> >> (jthread_self());
> > >>> > >> >> > > >> >> > > > > > > > >
> > >>> > >> >> > > >> >> > > > > > > > > Ok, I see. I agree that global
> > >>> > >> >> jni_native_intf should
> > >>> > >> >> > > >> >> not be used.
> > >>> > >> >> > > >> >> > > > > > > > > There was simple reason why I altered
> > >>> > >> >> such lines.
> > >>> > >> >> > > >> >> Because I changed
> > >>> > >> >> > > >> >> > > > > > > > > the type of jni_native_intf and no
> > >>> > >> >> casting operator
> > >>> > >> >> > > >> >> is needed now. To
> > >>> > >> >> > > >> >> > > > > > > > > be honest I think get_jni_env
> > >>> > >> >> (jthread_self()) can be
> > >>> > >> >> > > >> >> good as temporary
> > >>> > >> >> > > >> >> > > > > > > > > solution only. Lets wait for design of
> > >>> > >> >> multi VM and
> > >>> > >> >> > > >> >> fix it according
> > >>> > >> >> > > >> >> > > > > > > > > to it.
> > >>> > >> >> > > >> >> > > > > > > >
> > >>> > >> >> > > >> >> > > > > > > > While we are in JNI code, we always have
> > >>> > >> >> the JNIenv (at
> > >>> > >> >> > > >> >> least
> > >>> > >> >> > > >> >> > > > > > > > initially it comes from Java code).
> > >>> If we
> > >>> > >> >> consider VM
> > >>> > >> >> > > >> >> code as if it
> > >>> > >> >> > > >> >> > > > > > > > was a JNI application, then it seems
> > >>> like
> > >>> > >> >> we should be
> > >>> > >> >> > > >> >> just passing
> > >>> > >> >> > > >> >> > > > > > > > JNIEnv as a parameter to all
> > >>> functions in
> > >>> > >> >> VM. Or, we can
> > >>> > >> >> > > >> >> be taking it
> > >>> > >> >> > > >> >> > > > > > > > from TLS (via jthread_self()), depending
> > >>> > >> >> on which way is
> > >>> > >> >> > > >> >> faster...
> > >>> > >> >> > > >> >> > > > > > > Agree.
> > >>> > >> >> > > >> >> > > > > > >
> > >>> > >> >> > > >> >> > > > > > > >
> > >>> > >> >> > > >> >> > > > > > > > >
> > >>> > >> >> > > >> >> > > > > > > > > >
> > >>> > >> >> > > >> >> > > > > > > > > > 6). And small remarks:
> > >>> > >> >> > > >> >> > > > > > > > > > +jint vm_init1(JavaVM_Internal *
> > >>> > >> java_vm,
> > >>> > >> >> > > >> >> JavaVMInitArgs * vm_arguments);
> > >>> > >> >> > > >> >> > > > > > > > > > +jint vm_init2(JNIEnv_Internal *
> > >>> > >> >> jni_env);
> > >>> > >> >> > > >> >> > > > > > > > > > Could you make names more
> > >>> meaningful,
> > >>> > >> >> then 1,2,3...?
> > >>> > >> >> > > >> >> > > > > > > > > Ok, will do that.
> > >>> > >> >> > > >> >> > > > > > > > >
> > >>> > >> >> > > >> >> > > > > > > > > >
> > >>> > >> >> > > >> >> > > > > > > > > > class VM_thread {
> > >>> > >> >> > > >> >> > > > > > > > > > ...
> > >>> > >> >> > > >> >> > > > > > > > > > + JNIEnv_Internal * jni_env;
> > >>> > >> >> > > >> >> > > > > > > > > > The jthread already has the jni_env
> > >>> > >> >> pointer, you do
> > >>> > >> >> > > >> >> not need to
> > >>> > >> >> > > >> >> > > > > > > > > > duplicate it here.
> > >>> > >> >> > > >> >> > > > > > > > > > forexample by using
> > >>> > >> >> > > >> >> jthread_get_JNI_env(jthread_self());
> > >>> > >> >> > > >> >> > > > > > > > >
> > >>> > >> >> > > >> >> > > > > > > > > Yes I know. I don't see any problems
> > >>> > >> >> here. Some times
> > >>> > >> >> > > >> >> it is much more
> > >>> > >> >> > > >> >> > > > > > > > > convenient to get JNIEnv from
> > >>> VM_thread
> > >>> > >> >> structure (and
> > >>> > >> >> > > >> >> faster) instead
> > >>> > >> >> > > >> >> > > > > > > > > of doing jthread_get_JNI_env
> > >>> > >> (jthread_self
> > >>> > >> >> ()). So I
> > >>> > >> >> > > >> >> need strong
> > >>> > >> >> > > >> >> > > > > > > > > arguments for removing it. Again it
> > >>> > >> >> seems that should
> > >>> > >> >> > > >> >> be addressed in
> > >>> > >> >> > > >> >> > > > > > > > > design of multi VM. So lets forget
> > >>> about
> > >>> > >> >> it for a
> > >>> > >> >> > > >> >> while...
> > >>> > >> >> > > >> >> > > > > > > >
> > >>> > >> >> > > >> >> > > > > > > > I think that the data duplication would
> > >>> > >> >> always serve as
> > >>> > >> >> > > >> >> a potential
> > >>> > >> >> > > >> >> > > > > > > > source of errors - while updating one
> > >>> copy
> > >>> > >> >> of object,
> > >>> > >> >> > > >> >> you may forget
> > >>> > >> >> > > >> >> > > > > > > > to update the other, often resulting
> > >>> into
> > >>> > >> >> a strange
> > >>> > >> >> > > >> >> behavior of the
> > >>> > >> >> > > >> >> > > > > > > > whole application. Let's see what are
> > >>> the
> > >>> > >> >> specific
> > >>> > >> >> > > >> >> performance
> > >>> > >> >> > > >> >> > > > > > > > concerns that have to be addressed.
> > >>> To get
> > >>> > >> >> VM_thread
> > >>> > >> >> > > >> >> structure, you
> > >>> > >> >> > > >> >> > > > > > > > would eventually go to the TLS, just
> > >>> like
> > >>> > >> >> > > >> >> > > > > > > > jthread_get_JNI_env(jthread_self()
> > >>> > >> would do.
> > >>> > >> >> > > >> >> > > > > > > If there is already VM_thread structure
> > >>> for
> > >>> > >> >> some reasons
> > >>> > >> >> > > >> >> then there
> > >>> > >> >> > > >> >> > > > > > > will be no extra access to TLS. It is
> > >>> > >> >> definitely much
> > >>> > >> >> > > >> more in
> > >>> > >> >> > > >> >> > > > > > > jthread_get_JNI_env(jthread_self() than
> > >>> just
> > >>> > >> >> one TLS
> > >>> > >> >> > > >> >> access and one
> > >>> > >> >> > > >> >> > > > > > > dereferncing. I don't think it is a really
> > >>> > >> >> big problem
> > >>> > >> >> > > >> >> now. Do you
> > >>> > >> >> > > >> >> > > > > > > agree to look at this later. I guess
> > >>> > >> multi VM
> > >>> > >> >> > > >> >> implementation will
> > >>> > >> >> > > >> >> > > > > > > alter it in any case.
> > >>> > >> >> > > >> >> > > > > > >
> > >>> > >> >> > > >> >> > > > > > > Thanks
> > >>> > >> >> > > >> >> > > > > > > Evgueni
> > >>> > >> >> > > >> >> > > > > > >
> > >>> > >> >> > > >> >> > > > > > > >
> > >>> > >> >> > > >> >> > > > > > > > Thanks,
> > >>> > >> >> > > >> >> > > > > > > > Andrey.
> > >>> > >> >> > > >> >> > > > > > > >
> > >>> > >> >> > > >> >> > > > > > > > >
> > >>> > >> >> > > >> >> > > > > > > > > Evgueni
> > >>> > >> >> > > >> >> > > > > > > > > >
> > >>> > >> >> > > >> >> > > > > > > > > > Thanks
> > >>> > >> >> > > >> >> > > > > > > > > > Artem
> > >>> > >> >> > > >> >> > > > > > > > > >
> > >>> > >> >> > > >> >> > > > > > > > > > On 9/28/06, Evgueni Brevnov
> > >>> > >> >> > > >> >> <ev...@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.
> > >>> > >> >> > > >> >> > > > > > > > > > >
> > >>> > >> >> > > >> >> > > > > > > > > > > Thanks
> > >>> > >> >> > > >> >> > > > > > > > > > > Evgueni
> > >>> > >> >> > > >> >> > > > > > > > > > >
> > >>> > >> >> > > >> >> > > > > > > > > > > On 9/28/06, Geir Magnusson Jr.
> > >>> > >> >> <ge...@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
> > >>> > >> >> > > >> >> <we...@gmail.com> wrote:
> > >>> > >> >> > > >> >> > > > > > > > > > > > >> On 9/26/06, Evgueni Brevnov
> > >>> > >> >> > > >> >> <ev...@gmail.com> wrote:
> > >>> > >> >> > > >> >> > > > > > > > > > > > >> >
> > >>> > >> >> > > >> >> > > > > > > > > > > > >> > On 9/27/06, Andrey
> > >>> Chernyshev
> > >>> > >> >> > > >> >> <a....@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
> > >>> > >> >> > > >> >> > > > > > > > > > >
> > >>> > >> >> > > >> >> > > > > > > > > > >
> > >>> > >> >> > > >> >> > > > > > > > > >
> > >>> > >> >> > > >> >> > > > > > > > > >
> > >>> > >> >> > > >> >>
> > >>> > >> >>
> > >>> > >>
> > >>> ---------------------------------------------------------------------
> > >>> > >> >> > > >> >> > > > > > > > > > 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
> > >>> > >> >> > > >> >> > > > > > > > >
> > >>> > >> >> > > >> >> > > > > > > > >
> > >>> > >> >> > > >> >> > > > > > > >
> > >>> > >> >> > > >> >> > > > > > > >
> > >>> > >> >> > > >> >> > > > > > > > --
> > >>> > >> >> > > >> >> > > > > > > > Andrey Chernyshev
> > >>> > >> >> > > >> >> > > > > > > > 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
> > >>> > >> >> > > >> >> > > > > >
> > >>> > >> >> > > >> >> > > > > >
> > >>> > >> >> > > >> >> > > > >
> > >>> > >> >> > > >> >> > > > >
> > >>> > >> >> > > >> >> > > > > --
> > >>> > >> >> > > >> >> > > > > Andrey Chernyshev
> > >>> > >> >> > > >> >> > > > > 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
> > >>> > >> >> > > >> >> > > >
> > >>> > >> >> > > >> >> > > >
> > >>> > >> >> > > >> >> > >
> > >>> > >> >> > > >> >> > >
> > >>> > >> >> > > >> >> > > --
> > >>> > >> >> > > >> >> > > Andrey Chernyshev
> > >>> > >> >> > > >> >> > > 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
> > >>> > >> >> > > >>
> > >>> > >> >> > > >>
> > >>> > >> >> > > >
> > >>> > >> >> > > >
> > >>> > >> >>
> > >>> > >>
> > >>> ---------------------------------------------------------------------
> > >>> > >> >> > > > 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
> > >>> > >> >
> > >>> > >>
> > >>> > >>
> > >>> > >>
> > >>> ---------------------------------------------------------------------
> > >>> > >> 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
> > >>> >
> > >>> >
> > >>>
> > >>
> > >> ---------------------------------------------------------------------
> > >> 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
> >
> >
>
> ---------------------------------------------------------------------
> 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
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
Posted by Evgueni Brevnov <ev...@gmail.com>.
Ok, I go home. I have peace in my mind now :-)
Thank you all
Evgueni
On 10/9/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> ok - I just passed a smoke test, gc.PhantomReferenceQueueTest, that was
> failing. We should look at that and see why it's so flakey.
>
> If this works, I'm going to commit this thing so we can move forward.
>
> We should focus on stablizing the c-unit tests, btw...
>
> geir
>
>
> Geir Magnusson Jr. wrote:
> >
> >
> > Evgueni Brevnov wrote:
> >> Geir, Salikh,
> >>
> >> cunit tests are very unstable...... that's why we have different
> >> results on different platforms. It all tests problems. I already fixed
> >> several places but it seems there is much more left. I believe we need
> >> to revise them all. The main problem is that sleep(somthing) is used
> >> to synchronize different threads. Sometimes there is no synchraniztion
> >> at all. I propouse for switching it off until they get stable.
> >> Can we do it?
> >
> > No. They all pass for me now, and I think that they are important as
> > they are better than nothing.
> >
> > I suspected that these were just timing issues - we should just hunker
> > down and get them fixed ASAP. We're making progress
> >
> > geir
> >
> >>
> >> Evgueni
> >>
> >> On 10/9/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> >>> Could you insert sleep_a_click(); just before line 59 right after
> >>> hysem_create(&start, 0, 1):
> >>>
> >>> Does it help?
> >>>
> >>> On 10/9/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> >>> > [echo] ## Executing C unit test: test_ti_instrum
> >>> > [exec] Result: 1
> >>> > [echo] INFO: TEST test_jthread_get_all_threads start
> >>> > [echo] ERROR: Assertion '(thread_count)==(i +
> >>> > initial_thread_count)' failed at /home/geir/dev/apache/harmony/
> >>> > enhanced/trunk/working_vm/vm/tes
> >>> > ts/unit/thread/test_ti_instrum.c:94
> >>> > [echo] Init1: initial_thread_count=1, initial_all_threads_count=1
> >>> > [echo] Init3: initial_thread_count=1, initial_all_threads_count=1
> >>> > [echo] Init3: thread_count=3, all_threads_count=3
> >>> > [echo] INFO: TEST test_jthread_get_all_threads: FAILED
> >>> > [echo] INFO: TEST test_jthread_get_thread_count start
> >>> > [echo] Init1: initial_thread_count=3, initial_all_threads_count=3
> >>> > [echo] INFO: TEST test_jthread_get_thread_count: PASSED
> >>> > [echo] INFO: TEST test_jthread_get_blocked_count start
> >>> > [echo] INFO: TEST test_jthread_get_blocked_count: PASSED
> >>> > [echo] ## TEST FAILED
> >>> >
> >>> >
> >>> > On Oct 9, 2006, at 12:35 AM, Evgueni Brevnov wrote:
> >>> >
> >>> > > I put debug printing into test_ti_instrum.c and attached it to JIRA.
> >>> > > Could you run it on your machine and send me console output.
> >>> > >
> >>> > > Evgueni
> >>> > >
> >>> > > On 10/9/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> >>> > >> I keep getting a failure when running the tests -
> >>> > >>
> >>> > >> test_jthread_get_all-threads failling the assertion at
> >>> > >> test_ti_instrum.c:80
> >>> > >>
> >>> > >> geir
> >>> > >>
> >>> > >> On Oct 8, 2006, at 7:19 AM, Evgueni Brevnov wrote:
> >>> > >>
> >>> > >> > While running cunit on Linux it turned out one test case fails
> >>> some
> >>> > >> > time. The fix is in tests.final.2.patch.
> >>> > >> >
> >>> > >> > So the last versions to be committed:
> >>> > >> > invocation_api.final.patch
> >>> > >> > build.final.2.patch
> >>> > >> > tests.final.2.patch
> >>> > >> >
> >>> > >> > Evgueni
> >>> > >> >
> >>> > >> >
> >>> > >> > On 10/8/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> >>> > >> >> I mahaged to resolve the problem on Linux.... will update
> >>> > >> >> build.final.patch with build.final.2.patch in a while
> >>> > >> >>
> >>> > >> >> On 10/8/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> >>> > >> >> > Hi,
> >>> > >> >> >
> >>> > >> >> > Oh! Ooh! I did that..... I passed cunit, somke, kernel
> >>> tests on
> >>> > >> >> > Windows and smoke, kernel tests on Linux. Unfortunately I
> >>> > >> failed to
> >>> > >> >> > link cunit tests on Linux so far. So I disabled cunit on Linux
> >>> > >> >> until
> >>> > >> >> > the problem is solved. I believe it is acceptable as short
> >>> term
> >>> > >> >> > solution. I found several problems in cunit tests. I will come
> >>> > >> >> up with
> >>> > >> >> > my findings later (not today).
> >>> > >> >> >
> >>> > >> >> > Use latest patches from HARMONY-1582. They are marked as
> >>> final.
> >>> > >> >> There
> >>> > >> >> > are three patches. One for build module, one for cunit
> >>> tests and
> >>> > >> >> one
> >>> > >> >> > for VM itself.
> >>> > >> >> >
> >>> > >> >> > Thanks
> >>> > >> >> > Evgueni
> >>> > >> >> >
> >>> > >> >> >
> >>> > >> >> > On 10/6/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> >>> > >> >> > > Nooooooo! LOL
> >>> > >> >> > >
> >>> > >> >> > > I'm here waiting - This will unblock a whole bunch of
> >>> > >> things :)
> >>> > >> >> > >
> >>> > >> >> > > Thanks for the effort
> >>> > >> >> > >
> >>> > >> >> > > Evgueni Brevnov wrote:
> >>> > >> >> > > > Geir,
> >>> > >> >> > > >
> >>> > >> >> > > > That's terrible. We have power outage....servers are
> >>> down. I
> >>> > >> >> can't
> >>> > >> >> > > > send the patches now.... will do it tomorrow
> >>> > >> >> > > >
> >>> > >> >> > > > Evgueni
> >>> > >> >> > > > On 10/5/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> >>> > >> >> > > >> woo hoo! here we go...
> >>> > >> >> > > >>
> >>> > >> >> > > >>
> >>> > >> >> > > >> Andrey Chernyshev wrote:
> >>> > >> >> > > >> > Hi Evgueni,
> >>> > >> >> > > >> >
> >>> > >> >> > > >> > On 10/4/06, Evgueni Brevnov <ev...@gmail.com>
> >>> > >> >> wrote:
> >>> > >> >> > > >> >> Hi All,
> >>> > >> >> > > >> >>
> >>> > >> >> > > >> >> I have attached updated patch to the JIRA. It should
> >>> > >> >> resolve remain
> >>> > >> >> > > >> >> concerns. Andrey, could you give a green light now?
> >>> > >> >> > > >> >
> >>> > >> >> > > >> > Thanks for updating the patch! I agree it it can be
> >>> > >> >> committed, at
> >>> > >> >> > > >> > least signatures look good. 5 revisions seem like more
> >>> > >> >> than enough :).
> >>> > >> >> > > >> > Anyways, I think the remaining issues can be resolved
> >>> > >> >> with additional
> >>> > >> >> > > >> > patches. Thanks again for the good work and your
> >>> > >> patience.
> >>> > >> >> > > >> >
> >>> > >> >> > > >> > Thanks,
> >>> > >> >> > > >> > Andrey.
> >>> > >> >> > > >> >
> >>> > >> >> > > >> >>
> >>> > >> >> > > >> >> Thanks
> >>> > >> >> > > >> >> Evgueni
> >>> > >> >> > > >> >>
> >>> > >> >> > > >> >> On 10/4/06, Evgueni Brevnov
> >>> <ev...@gmail.com>
> >>> > >> >> wrote:
> >>> > >> >> > > >> >> > Andrey,
> >>> > >> >> > > >> >> >
> >>> > >> >> > > >> >> > I see your points. I think both approaches have
> >>> > >> >> advantages and
> >>> > >> >> > > >> >> > disadvantages. I think it is quite hard to say which
> >>> > >> >> approach is
> >>> > >> >> > > >> >> > better until we play with one VM only. I still feel
> >>> > >> >> like introducing
> >>> > >> >> > > >> >> > one more dependence is better than spreading code
> >>> > >> >> which deals with
> >>> > >> >> > > >> >> > attachment among VM and TM. We really get stuck. OK,
> >>> > >> >> just because I
> >>> > >> >> > > >> >> > want to move forward I will do required changes to
> >>> > >> remove
> >>> > >> >> > > >> >> > vm_create_jthread from TM. I believe that will
> >>> resolve
> >>> > >> >> all our
> >>> > >> >> > > >> >> > disagreements and the patch will be applied soon.
> >>> > >> >> > > >> >> >
> >>> > >> >> > > >> >> >
> >>> > >> >> > > >> >> > Thanks
> >>> > >> >> > > >> >> > Evgueni.
> >>> > >> >> > > >> >> >
> >>> > >> >> > > >> >> > On 10/4/06, Andrey Chernyshev
> >>> > >> >> <a....@gmail.com> wrote:
> >>> > >> >> > > >> >> > > On 10/3/06, Evgueni Brevnov
> >>> > >> >> <ev...@gmail.com> wrote:
> >>> > >> >> > > >> >> > > > On 10/3/06, Andrey Chernyshev
> >>> > >> >> <a....@gmail.com> wrote:
> >>> > >> >> > > >> >> > > > > On 10/2/06, Evgueni Brevnov
> >>> > >> >> <ev...@gmail.com> wrote:
> >>> > >> >> > > >> >> > > > > > Andrey,
> >>> > >> >> > > >> >> > > > > >
> >>> > >> >> > > >> >> > > > > > Just to be clear.... I agree with you it is
> >>> > >> more
> >>> > >> >> > > >> convenient if
> >>> > >> >> > > >> >> > > > > > jthread_create takes JNIEnv instead of
> >>> > >> JavaVM. It
> >>> > >> >> > > >> reflects that
> >>> > >> >> > > >> >> > > > > > current thread has been attached already. Do
> >>> > >> >> you think it
> >>> > >> >> > > >> >> makes sense
> >>> > >> >> > > >> >> > > > > > to get rid of JNIEnv and use
> >>> > >> >> jthread_get_JNI_env in that
> >>> > >> >> > > >> case?
> >>> > >> >> > > >> >> > > > >
> >>> > >> >> > > >> >> > > > > The jthread_* layer is designed like if it
> >>> were
> >>> > >> >> a regular JNI
> >>> > >> >> > > >> >> > > > > application which is meant to be called
> >>> from the
> >>> > >> >> Java code,
> >>> > >> >> > > >> hence
> >>> > >> >> > > >> >> > > > > every function on that layer receives
> >>> JNIenv. We
> >>> > >> >> can probably
> >>> > >> >> > > >> >> get rid
> >>> > >> >> > > >> >> > > > > of the JNEnv parameter for jthread_*
> >>> functions,
> >>> > >> >> assuming that
> >>> > >> >> > > >> >> TM can
> >>> > >> >> > > >> >> > > > > always extract JNIenv for the current thread
> >>> > >> with
> >>> > >> >> > > >> >> > > > > jthread_get_JNI_env().
> >>> > >> >> > > >> >> > > > > My only concern would be the performance -
> >>> once
> >>> > >> >> the JNIenv is
> >>> > >> >> > > >> >> already
> >>> > >> >> > > >> >> > > > > known for the native part of the kernel
> >>> classes
> >>> > >> >> impl, it
> >>> > >> >> > > >> must be
> >>> > >> >> > > >> >> > > > > cheaper to pass JNIEnv to TM as an extra
> >>> > >> >> parameter rather than
> >>> > >> >> > > >> >> extract
> >>> > >> >> > > >> >> > > > > it from the TLS again.
> >>> > >> >> > > >> >> > > > > Other than that, I see no strong advantages in
> >>> > >> >> keeping JNIEnv
> >>> > >> >> > > >> >> parameter.
> >>> > >> >> > > >> >> > > > >
> >>> > >> >> > > >> >> > > > >
> >>> > >> >> > > >> >> > > > > > Regarding jthread_attach. I still didn't get
> >>> > >> >> your point....
> >>> > >> >> > > >> >> Clarify it
> >>> > >> >> > > >> >> > > > > > please if you think jhread_attach should be
> >>> > >> >> modified.
> >>> > >> >> > > >> >> > > > >
> >>> > >> >> > > >> >> > > > > Sorry for being not clear: I think for
> >>> > >> >> jthread_attach, we have
> >>> > >> >> > > >> >> two options:
> >>> > >> >> > > >> >> > > > > 1) Make JNIEnv input parameter - it must be
> >>> new
> >>> > >> >> JNIEnv that VM
> >>> > >> >> > > >> >> > > > > pre-allocates for the new Java thread.
> >>> > >> >> jthread_attach
> >>> > >> >> > > >> would just
> >>> > >> >> > > >> >> > > > > associate it with the current thread.
> >>> > >> >> > > >> >> > > > >
> >>> > >> >> > > >> >> > > > > 2) Obtain JNIEnv via vm_attach() callback. In
> >>> > >> >> this case, if
> >>> > >> >> > > >> >> > > > > vm_attach() callback implementation needs to
> >>> > >> >> know for which
> >>> > >> >> > > >> >> JavaVM new
> >>> > >> >> > > >> >> > > > > JNIenv has to be allocated, then we'll need to
> >>> > >> >> add JavaVM as
> >>> > >> >> > > >> >> input
> >>> > >> >> > > >> >> > > > > parameter for jthread_attach().
> >>> > >> >> > > >> >> > > > > I think both options should be fine, (1) would
> >>> > >> >> probably
> >>> > >> >> > > >> keep TM
> >>> > >> >> > > >> >> > > > > interface a bit lighter, though (2) may look
> >>> > >> >> more closer to
> >>> > >> >> > > >> >> the JNI
> >>> > >> >> > > >> >> > > > > invocation API idea.
> >>> > >> >> > > >> >> > > > > So I think adding JavaVM specifically for
> >>> > >> >> jthread_attach
> >>> > >> >> > > >> may make
> >>> > >> >> > > >> >> > > > > sense given the explanation you provided
> >>> > >> earlier.
> >>> > >> >> > > >> >> > > > >
> >>> > >> >> > > >> >> > > > > The concern I would have regarding the
> >>> proposed
> >>> > >> >> jthread_attach
> >>> > >> >> > > >> >> > > > > implementation is a call to
> >>> vm_create_jthread()
> >>> > >> >> - this call
> >>> > >> >> > > >> >> introduces
> >>> > >> >> > > >> >> > > > > an extra dependency of TM on vmcore that I'd
> >>> > >> >> prefer to be
> >>> > >> >> > > >> >> avoided. In
> >>> > >> >> > > >> >> > > > > the original version, jthread_attach() was
> >>> > >> >> taking jthread
> >>> > >> >> > > >> >> argument of
> >>> > >> >> > > >> >> > > > > the already prepared j.l.Thread.
> >>> > >> >> > > >> >> > > >
> >>> > >> >> > > >> >> > > > I understand your concern. Unfortunately I don't
> >>> > >> >> see what we
> >>> > >> >> > > >> can do
> >>> > >> >> > > >> >> > > > here. Let me explain. In the beginning you
> >>> have an
> >>> > >> >> unattached
> >>> > >> >> > > >> >> native
> >>> > >> >> > > >> >> > > > thread. To be able to call java code (which is
> >>> > >> >> required for
> >>> > >> >> > > >> >> > > > constructing j.l.Thread instance) the thread
> >>> > >> >> should be attached
> >>> > >> >> > > >> >> first.
> >>> > >> >> > > >> >> > > > To be specific it should be attached to VM by
> >>> > >> >> calling vm_attach
> >>> > >> >> > > >> >> which
> >>> > >> >> > > >> >> > > > will return a valid JNIEnv It is valid to use
> >>> JNI
> >>> > >> >> from that
> >>> > >> >> > > >> moment.
> >>> > >> >> > > >> >> > > > Obtained JNIEnv can be used to execute java code
> >>> > >> >> and create
> >>> > >> >> > > >> >> j.l.Thread
> >>> > >> >> > > >> >> > > > instance. Since we do vm_attach in
> >>> jthread_attach
> >>> > >> >> we need to do
> >>> > >> >> > > >> >> > > > vm_create_jthread inside jthread_atach as well.
> >>> > >> >> > > >> >> > > > Of course it can be an alternative to do
> >>> vm_attach
> >>> > >> >> and
> >>> > >> >> > > >> >> > > > vm_create_jthread outside of TM right before
> >>> > >> >> jthread_attach.
> >>> > >> >> > > >> >> Sure it
> >>> > >> >> > > >> >> > > > will reduce one dependence between VM and TM.
> >>> But
> >>> > >> >> it seems like
> >>> > >> >> > > >> >> > > > artificial action for me just because of
> >>> > >> >> dependency....
> >>> > >> >> > > >> >> > >
> >>> > >> >> > > >> >> > > Why do you think it is artificial? I would rather
> >>> > >> >> prefer not to
> >>> > >> >> > > >> throw
> >>> > >> >> > > >> >> > > vm_attach event from the jthread_attach() call at
> >>> > >> >> all than to add
> >>> > >> >> > > >> >> > > extra dependency. The idea of jthread layer is a
> >>> > >> >> Java face to
> >>> > >> >> > > >> >> > > hythread, it is meant to know either a little or
> >>> > >> >> nothing about the
> >>> > >> >> > > >> >> > > rest of VM. It may be logical to throw vm_attach
> >>> > >> >> call from the
> >>> > >> >> > > >> newly
> >>> > >> >> > > >> >> > > created thread, because there is no other way
> >>> to let
> >>> > >> >> know VM
> >>> > >> >> > > >> the new
> >>> > >> >> > > >> >> > > thread is created. VM attach is a different case -
> >>> > >> >> VM already
> >>> > >> >> > > >> knows
> >>> > >> >> > > >> >> > > about new Java thread at the time of the
> >>> > >> >> AttachCurrentThread call.
> >>> > >> >> > > >> >> > >
> >>> > >> >> > > >> >> > > >
> >>> > >> >> > > >> >> > > > > Do you think it makes sense to replace a
> >>> single
> >>> > >> >> jthread
> >>> > >> >> > > >> >> parameter with
> >>> > >> >> > > >> >> > > > > a variety of stuff (like thread group,
> >>> name)? It
> >>> > >> >> seems the
> >>> > >> >> > > >> only
> >>> > >> >> > > >> >> > > > > purpose of at these args is to be passed
> >>> back to
> >>> > >> >> VM for
> >>> > >> >> > > >> >> > > > > vm_jthread_create(). I would suggest to change
> >>> > >> >> this and try
> >>> > >> >> > > >> doing
> >>> > >> >> > > >> >> > > > > either of:
> >>> > >> >> > > >> >> > > > > 1) Make signature of jthread_attach with 3
> >>> args,
> >>> > >> >> JavaVM,
> >>> > >> >> > > >> >> jthread and the daemon.
> >>> > >> >> > > >> >> > > > Why do you want to pass daemon to TM but
> >>> thread's
> >>> > >> >> name and
> >>> > >> >> > > >> >> group. Just
> >>> > >> >> > > >> >> > > > because current TM doesn't need such
> >>> information?
> >>> > >> >> What if it is
> >>> > >> >> > > >> >> > > > required to get thread name later? Say by
> >>> > >> introducing
> >>> > >> >> > > >> >> > >
> >>> > >> >> > > >> >> > > I imagine you need a daemon attribute since the TM
> >>> > >> >> is still
> >>> > >> >> > > >> managing
> >>> > >> >> > > >> >> > > the thread daemonality. TM is not managing thread
> >>> > >> >> name and group -
> >>> > >> >> > > >> >> > > they are all kept on the Java level, hence passing
> >>> > >> >> them may be
> >>> > >> >> > > >> >> > > excessive.
> >>> > >> >> > > >> >> > >
> >>> > >> >> > > >> >> > > > jthread_get_name... What will you do in that
> >>> case?
> >>> > >> >> Let me
> >>> > >> >> > > >> guess you
> >>> > >> >> > > >> >> > > > will call j.l.Thread.getName. Right. Ok! In that
> >>> > >> >> case I see no
> >>> > >> >> > > >> >> > > > problems to call j.l.Thread.isDaemon. Do you
> >>> > >> >> agree? So it
> >>> > >> >> > > >> doesn't
> >>> > >> >> > > >> >> > >
> >>> > >> >> > > >> >> > > As I suggested earlier, the best way to handle
> >>> > >> >> daemonality would
> >>> > >> >> > > >> >> > > probably be in pure Java - in j.l.Thread (or
> >>> > >> >> > > >> j.l.VMThreadManager) or
> >>> > >> >> > > >> >> > > whatever. You already lifted it up to the jthread
> >>> > >> >> level, but
> >>> > >> >> > > >> what if
> >>> > >> >> > > >> >> > > we can go a little bit higher...
> >>> > >> >> > > >> >> > >
> >>> > >> >> > > >> >> > > > seems to be a good design to pass only part
> >>> of the
> >>> > >> >> > > >> information to
> >>> > >> >> > > >> >> > > > jthread_atach. Lets look at the signature of
> >>> > >> >> > > >> >> AttachCurrentThread. It
> >>> > >> >> > > >> >> > > > takes exactly these three parameters (daemon,
> >>> > >> >> name, group)
> >>> > >> >> > > >> >> passed as a
> >>> > >> >> > > >> >> > > > structure. I was thinking about having
> >>> exactly the
> >>> > >> >> same
> >>> > >> >> > > >> >> structure as
> >>> > >> >> > > >> >> > > > third parameter of jthread_attach but it occured
> >>> > >> >> to be more
> >>> > >> >> > > >> >> convinient
> >>> > >> >> > > >> >> > > > to pass them seperatly. Although I don't see
> >>> > >> >> strong reasons
> >>> > >> >> > > >> against
> >>> > >> >> > > >> >> > > > having a structure a third parameter.
> >>> > >> >> > > >> >> > >
> >>> > >> >> > > >> >> > > I see. Acually, I would love to keep the
> >>> > >> >> jthread_attach func-ty at
> >>> > >> >> > > >> >> the
> >>> > >> >> > > >> >> > > minimum level which will be needed to handle the
> >>> > >> >> only data that TM
> >>> > >> >> > > >> >> > > should be aware of. We need a formal boundary
> >>> > >> >> between jthread
> >>> > >> >> > > >> layer
> >>> > >> >> > > >> >> > > and vmcore (otherwise jthread won't have a much of
> >>> > >> >> sense, one may
> >>> > >> >> > > >> >> > > consider it just as a convenience set of functions
> >>> > >> >> in vmcore which
> >>> > >> >> > > >> >> are
> >>> > >> >> > > >> >> > > doing something with threading).
> >>> > >> >> > > >> >> > >
> >>> > >> >> > > >> >> > > >
> >>> > >> >> > > >> >> > > > > 2) Move the implementation of
> >>> vm_create_jtrhead
> >>> > >> >> () to
> >>> > >> >> > > >> >> > > > > thread_java_basic.c - could it be written in
> >>> > >> >> pure JNI without
> >>> > >> >> > > >> >> using
> >>> > >> >> > > >> >> > > > > internal VM API like class_alloc_new_object()?
> >>> > >> >> > > >> >> > > >
> >>> > >> >> > > >> >> > > > Yes, this can be done but it doesn't fix the
> >>> > >> >> problem. You still
> >>> > >> >> > > >> >> need
> >>> > >> >> > > >> >> > > > to know about internal constructor of j.l.Thread
> >>> > >> >> > > >> >> > >
> >>> > >> >> > > >> >> > > That's bad. Given what you said, now it seems that
> >>> > >> >> the most
> >>> > >> >> > > >> >> preferable
> >>> > >> >> > > >> >> > > sequence for AttachCurrentThread impl still
> >>> would be
> >>> > >> >> like:
> >>> > >> >> > > >> >> > > JNIEnv = vm_attach();
> >>> > >> >> > > >> >> > > jthread = create_jthread(JNIenv)
> >>> > >> >> > > >> >> > > jthread_attach(JNIEnv, jthread) // stores
> >>> JNIEnv and
> >>> > >> >> Hythread into
> >>> > >> >> > > >> >> > > TLS, doesn't call vm_attach any longer.
> >>> > >> >> > > >> >> > > - this is almost what we had from the beginning...
> >>> > >> >> > > >> >> > >
> >>> > >> >> > > >> >> > > Thanks,
> >>> > >> >> > > >> >> > > Andrey.
> >>> > >> >> > > >> >> > >
> >>> > >> >> > > >> >> > > >
> >>> > >> >> > > >> >> > > >
> >>> > >> >> > > >> >> > > > Thanks
> >>> > >> >> > > >> >> > > > Evgueni
> >>> > >> >> > > >> >> > > > >
> >>> > >> >> > > >> >> > > > >
> >>> > >> >> > > >> >> > > > > Thanks,
> >>> > >> >> > > >> >> > > > > Andrey.
> >>> > >> >> > > >> >> > > > >
> >>> > >> >> > > >> >> > > > > >
> >>> > >> >> > > >> >> > > > > > Thank you
> >>> > >> >> > > >> >> > > > > > Evgueni
> >>> > >> >> > > >> >> > > > > >
> >>> > >> >> > > >> >> > > > > > On 10/2/06, Evgueni Brevnov
> >>> > >> >> <ev...@gmail.com>
> >>> > >> >> > > >> wrote:
> >>> > >> >> > > >> >> > > > > > > On 9/29/06, Andrey Chernyshev
> >>> > >> >> <a....@gmail.com>
> >>> > >> >> > > >> >> wrote:
> >>> > >> >> > > >> >> > > > > > > > On 9/29/06, Evgueni Brevnov
> >>> > >> >> <ev...@gmail.com>
> >>> > >> >> > > >> >> wrote:
> >>> > >> >> > > >> >> > > > > > > > > Artem,
> >>> > >> >> > > >> >> > > > > > > > >
> >>> > >> >> > > >> >> > > > > > > > > Thank you for your feedback....
> >>> find my
> >>> > >> >> inlined.....
> >>> > >> >> > > >> >> > > > > > > > >
> >>> > >> >> > > >> >> > > > > > > > > On 9/29/06, Artem Aliev
> >>> > >> >> <ar...@gmail.com> wrote:
> >>> > >> >> > > >> >> > > > > > > > > > Evgueni,
> >>> > >> >> > > >> >> > > > > > > > > >
> >>> > >> >> > > >> >> > > > > > > > > > I got most of your changes, but
> >>> still
> >>> > >> >> disagree
> >>> > >> >> > > >> with all
> >>> > >> >> > > >> >> > > > > > > > > > hythread/jthread interface changes.
> >>> > >> >> Could leave
> >>> > >> >> > > >> >> interface unchanged.
> >>> > >> >> > > >> >> > > > > > > > > > See following possible solutions,
> >>> that
> >>> > >> >> could solve
> >>> > >> >> > > >> >> the same problems
> >>> > >> >> > > >> >> > > > > > > > > > without interface changes.
> >>> > >> >> > > >> >> > > > > > > > > >
> >>> > >> >> > > >> >> > > > > > > > > >
> >>> > >> >> > > >> >> > > > > > > > > > 1) daemon attribute is a java
> >>> > >> >> specific. (Andrey
> >>> > >> >> > > >> >> mentioned this already).
> >>> > >> >> > > >> >> > > > > > > > > > Could you please move it back. to
> >>> > >> >> the jthread
> >>> > >> >> > > >> >> layer. It is better
> >>> > >> >> > > >> >> > > > > > > > > > to rename
> >>> > >> >> > > >> >> > > > > > > > > >
> >>> > >> >> hythread_wait_for_all_nondaemon_threads() to
> >>> > >> >> > > >> >> > > > > > > > > >
> >>> > >> jthread_wait_for_all_nondaemon_threads().
> >>> > >> >> > > >> >> > > > > > > > > Ok, I see no problems to move "daemon"
> >>> > >> >> to java layer.
> >>> > >> >> > > >> >> In that case:
> >>> > >> >> > > >> >> > > > > > > > > 1) I will move
> >>> > >> >> > > >> >> hythread_wait_for_all_nondaemon_threads() from
> >>> > >> >> > > >> >> > > > > > > > > thread_init.c to one which implements
> >>> > >> >> java layer.
> >>> > >> >> > > >> >> > > > > > > > > 2) I will move daemon field from
> >>> > >> >> HyThread structure.
> >>> > >> >> > > >> >> > > > > > > > >
> >>> > >> >> > > >> >> > > > > > > > > Agree?
> >>> > >> >> > > >> >> > > > > > > >
> >>> > >> >> > > >> >> > > > > > > > Sounds good to me.
> >>> > >> >> > > >> >> > > > > > >
> >>> > >> >> > > >> >> > > > > > > OK, will do that.
> >>> > >> >> > > >> >> > > > > > >
> >>> > >> >> > > >> >> > > > > > > >
> >>> > >> >> > > >> >> > > > > > > >
> >>> > >> >> > > >> >> > > > > > > > >
> >>> > >> >> > > >> >> > > > > > > > > >
> >>> > >> >> > > >> >> > > > > > > > > > 2) JavaVM could be retrieved from
> >>> > >> >> JNIEnv by
> >>> > >> >> > > >> >> jni_get_java_vm(). So
> >>> > >> >> > > >> >> > > > > > > > > > let the jthread_create() and
> >>> others to
> >>> > >> >> use JNIEnv
> >>> > >> >> > > >> >> (that is passed from
> >>> > >> >> > > >> >> > > > > > > > > > java native method).
> >>> > >> >> > > >> >> > > > > > > > > > The vm_attach could get old JNI env
> >>> > >> >> and create new
> >>> > >> >> > > >> >> one for the new thread.
> >>> > >> >> > > >> >> > > > > > > > > > The first JNIEnv is created in
> >>> > >> >> CreateVM call and
> >>> > >> >> > > >> >> could be passed to
> >>> > >> >> > > >> >> > > > > > > > > > the first thread at startup.
> >>> > >> >> > > >> >> > > > > > > > > No, no, no. I completely disagree with
> >>> > >> >> that!!! Why do
> >>> > >> >> > > >> >> you like JNIEnv
> >>> > >> >> > > >> >> > > > > > > > > but JavaVM. Why do you think that
> >>> > >> >> passing JavaVM
> >>> > >> >> > > >> >> instead of JNIEnv
> >>> > >> >> > > >> >> > > > > > > > > makes TM less modular? I don't see any
> >>> > >> >> difference
> >>> > >> >> > > >> >> here.... It seems
> >>> > >> >> > > >> >> > > > > > > > > for me like a big big hack to grab
> >>> > >> >> JNIEnv from another
> >>> > >> >> > > >> >> thread and pass
> >>> > >> >> > > >> >> > > > > > > > > it to jthread_attach to perform
> >>> > >> >> operations in the
> >>> > >> >> > > >> >> current thread.
> >>> > >> >> > > >> >> > > > > > > >
> >>> > >> >> > > >> >> > > > > > > > TM needs to know JNIEnv, mainly for
> >>> > >> >> managing the
> >>> > >> >> > > >> >> references to
> >>> > >> >> > > >> >> > > > > > > > objects, throwing exceptions and calling
> >>> > >> >> run() method of
> >>> > >> >> > > >> >> a new thread.
> >>> > >> >> > > >> >> > > > > > > > JNI spec proposes that JNIEnv is valid
> >>> > >> >> within the given
> >>> > >> >> > > >> >> thread, this
> >>> > >> >> > > >> >> > > > > > > > is why TM holds the JNIEnv pointer at
> >>> the
> >>> > >> >> moment. This
> >>> > >> >> > > >> >> is why TM likes
> >>> > >> >> > > >> >> > > > > > > > the JNIEnv.
> >>> > >> >> > > >> >> > > > > > > >
> >>> > >> >> > > >> >> > > > > > > > Having the JNIEnv, one is able to get
> >>> > >> >> JavaVM but not
> >>> > >> >> > > >> >> vise versa. This
> >>> > >> >> > > >> >> > > > > > > > is why TM doesn't like the JavaVM :)
> >>> > >> >> > > >> >> > > > > > > I see your point. Only one note this is
> >>> true
> >>> > >> >> for already
> >>> > >> >> > > >> >> attached threads...
> >>> > >> >> > > >> >> > > > > > >
> >>> > >> >> > > >> >> > > > > > > >
> >>> > >> >> > > >> >> > > > > > > > I agree with you that there is a design
> >>> > >> >> flaw that the
> >>> > >> >> > > >> >> JNIEnv is copied
> >>> > >> >> > > >> >> > > > > > > > from the parent thread to a child thread
> >>> > >> >> during thread
> >>> > >> >> > > >> >> creation. I
> >>> > >> >> > > >> >> > > > > > > > think it could be resolved via
> >>> vm_attach()
> >>> > >> >> hook - with
> >>> > >> >> > > >> >> this event, VM
> >>> > >> >> > > >> >> > > > > > > > might tell the TM what the JNIEnv
> >>> pointer
> >>> > >> >> for new thread
> >>> > >> >> > > >> >> should be. I
> >>> > >> >> > > >> >> > > > > > > > think you did that by extending the
> >>> > >> >> vm_attach() call
> >>> > >> >> > > >> >> with the JNIEnv**
> >>> > >> >> > > >> >> > > > > > > > argument.
> >>> > >> >> > > >> >> > > > > > > >
> >>> > >> >> > > >> >> > > > > > > > What is not completely clear is, why do
> >>> > >> >> you have to pass
> >>> > >> >> > > >> >> the JavaVM
> >>> > >> >> > > >> >> > > > > > > > forth and back, once from VM to TM, and
> >>> > >> >> then back from
> >>> > >> >> > > >> >> TM to VM again?
> >>> > >> >> > > >> >> > > > > > > >
> >>> > >> >> > > >> >> > > > > > > > If you need to know in jthread_attach,
> >>> > >> >> which particular
> >>> > >> >> > > >> >> VM vm_attach()
> >>> > >> >> > > >> >> > > > > > > > event is coming from, you could have
> >>> > >> >> vm_attach like
> >>> > >> >> > > >> >> > > > > > > > vm_attach(JNIEnv* currentThreadEnv,
> >>> > >> JNIEnv**
> >>> > >> >> > > >> >> newThreadEnv).
> >>> > >> >> > > >> >> > > > > > > I'm a little bit confused.....Current
> >>> thread
> >>> > >> >> hasn't been
> >>> > >> >> > > >> >> attached yet.
> >>> > >> >> > > >> >> > > > > > > So there is no JNIEnv for it yet. How
> >>> it can
> >>> > >> >> be passed as
> >>> > >> >> > > >> >> the first
> >>> > >> >> > > >> >> > > > > > > parameter to vm_attach()?
> >>> > >> >> > > >> >> > > > > > >
> >>> > >> >> > > >> >> > > > > > > > Then you will be always able to get the
> >>> > >> >> JavaVM from the
> >>> > >> >> > > >> >> JNIEnv.
> >>> > >> >> > > >> >> > > > > > > > The only difference is that you are
> >>> > >> >> currently doing
> >>> > >> >> > > >> >> JNIEnv->JavaVM
> >>> > >> >> > > >> >> > > > > > > > conversion in the VMThreadManager,
> >>> but why
> >>> > >> >> can't you
> >>> > >> >> > > >> >> just do this in
> >>> > >> >> > > >> >> > > > > > > > vm_attach() without changing the
> >>> interface
> >>> > >> >> of the TM?
> >>> > >> >> > > >> >> > > > > > > > So far JavaVM really looks like an extra
> >>> > >> >> knowledge that
> >>> > >> >> > > >> >> TM doesn't
> >>> > >> >> > > >> >> > > > > > > > have to be aware of.
> >>> > >> >> > > >> >> > > > > > > >
> >>> > >> >> > > >> >> > > > > > > > > Moreover there is no JNIEnv when main
> >>> > >> >> thread attaches
> >>> > >> >> > > >> >> to VM. So we
> >>> > >> >> > > >> >> > > > > > > > > should either keep it as is or change
> >>> > >> >> original design
> >>> > >> >> > > >> >> of TM and attach
> >>> > >> >> > > >> >> > > > > > > > > thread to VM before attaching it to
> >>> TM.
> >>> > >> >> In that case
> >>> > >> >> > > >> >> we will have
> >>> > >> >> > > >> >> > > > > > > > > valid JNIEnv which can be passed to
> >>> > >> >> jthread_atatch. We
> >>> > >> >> > > >> >> need to think
> >>> > >> >> > > >> >> > > > > > > > > over it twice before changing
> >>> > >> something....
> >>> > >> >> > > >> >> > > > > > > >
> >>> > >> >> > > >> >> > > > > > > > Right. For jthread_attach, JNIenv
> >>> needs to
> >>> > >> >> be changed
> >>> > >> >> > > >> >> from being input
> >>> > >> >> > > >> >> > > > > > > > parameter to being the output parameter.
> >>> > >> >> The way how
> >>> > >> >> > > >> >> JNIenv is
> >>> > >> >> > > >> >> > > > > > > > obtained by TM should be vm_attach()
> >>> > >> event.
> >>> > >> >> > > >> >> > > > > > > OK, JNIEnv is output parameter. And it
> >>> > >> >> obtained by
> >>> > >> >> > > >> >> vm_attach(). This
> >>> > >> >> > > >> >> > > > > > > is exactly like I do in the patch. What I
> >>> > >> >> don't understand
> >>> > >> >> > > >> >> is how
> >>> > >> >> > > >> >> > > > > > > jthread_attach knows to which VM the
> >>> thread
> >>> > >> >> should be
> >>> > >> >> > > >> >> attached? Do you
> >>> > >> >> > > >> >> > > > > > > suggest calling vm_attach first to create
> >>> > >> >> JNIEnv it pass
> >>> > >> >> > > >> >> it to
> >>> > >> >> > > >> >> > > > > > > jthread_attach?
> >>> > >> >> > > >> >> > > > > > >
> >>> > >> >> > > >> >> > > > > > > >
> >>> > >> >> > > >> >> > > > > > > > >
> >>> > >> >> > > >> >> > > > > > > > >
> >>> > >> >> > > >> >> > > > > > > > >
> >>> > >> >> > > >> >> > > > > > > > > >
> >>> > >> >> > > >> >> > > > > > > > > >
> >>> > >> >> > > >> >> > > > > > > > > > 4) Original classlib hythread do
> >>> > >> not use
> >>> > >> >> > > >> >> hythread_library_t in arguments,
> >>> > >> >> > > >> >> > > > > > > > > > It uses following code:
> >>> > >> >> > > >> >> > > > > > > > > >
> >>> > >> >> > > >> >> > > > > > > > > > hythread_library_t lib =
> >>> GLOBAL_DATA
> >>> > >> >> > > >> >> (default_library);
> >>> > >> >> > > >> >> > > > > > > > > > or
> >>> > >> >> > > >> >> > > > > > > > > > hythread_library_t library =
> >>> thread-
> >>> > >> >> >library;
> >>> > >> >> > > >> >> > > > > > > > > >
> >>> > >> >> > > >> >> > > > > > > > > > So could you please use the same
> >>> > >> >> mechanism and
> >>> > >> >> > > >> >> remove hythread_*_ex >functions.
> >>> > >> >> > > >> >> > > > > > > > > Let's see if classlib's hythread needs
> >>> > >> >> changing first.
> >>> > >> >> > > >> >> It seems for me
> >>> > >> >> > > >> >> > > > > > > > > such code prevents us from having
> >>> > >> multi VM.
> >>> > >> >> > > >> >> > > > > > > > >
> >>> > >> >> > > >> >> > > > > > > > > >
> >>> > >> >> > > >> >> > > > > > > > > > 5. You introduce more then one jni
> >>> > >> >> env, but still
> >>> > >> >> > > >> >> use global variable for it.
> >>> > >> >> > > >> >> > > > > > > > > > So all changes like following:
> >>> > >> >> > > >> >> > > > > > > > > > - JNIEnv *jenv = (JNIEnv*)
> >>> > >> >> jni_native_intf;
> >>> > >> >> > > >> >> > > > > > > > > > + JNIEnv *jenv = jni_native_intf;
> >>> > >> >> > > >> >> > > > > > > > > >
> >>> > >> >> > > >> >> > > > > > > > > > should be like:
> >>> > >> >> > > >> >> > > > > > > > > > - JNIEnv *jenv = (JNIEnv*)
> >>> > >> >> jni_native_intf;
> >>> > >> >> > > >> >> > > > > > > > > > + JNIEnv *jenv = get_jni_env
> >>> > >> >> (jthread_self());
> >>> > >> >> > > >> >> > > > > > > > >
> >>> > >> >> > > >> >> > > > > > > > > Ok, I see. I agree that global
> >>> > >> >> jni_native_intf should
> >>> > >> >> > > >> >> not be used.
> >>> > >> >> > > >> >> > > > > > > > > There was simple reason why I altered
> >>> > >> >> such lines.
> >>> > >> >> > > >> >> Because I changed
> >>> > >> >> > > >> >> > > > > > > > > the type of jni_native_intf and no
> >>> > >> >> casting operator
> >>> > >> >> > > >> >> is needed now. To
> >>> > >> >> > > >> >> > > > > > > > > be honest I think get_jni_env
> >>> > >> >> (jthread_self()) can be
> >>> > >> >> > > >> >> good as temporary
> >>> > >> >> > > >> >> > > > > > > > > solution only. Lets wait for design of
> >>> > >> >> multi VM and
> >>> > >> >> > > >> >> fix it according
> >>> > >> >> > > >> >> > > > > > > > > to it.
> >>> > >> >> > > >> >> > > > > > > >
> >>> > >> >> > > >> >> > > > > > > > While we are in JNI code, we always have
> >>> > >> >> the JNIenv (at
> >>> > >> >> > > >> >> least
> >>> > >> >> > > >> >> > > > > > > > initially it comes from Java code).
> >>> If we
> >>> > >> >> consider VM
> >>> > >> >> > > >> >> code as if it
> >>> > >> >> > > >> >> > > > > > > > was a JNI application, then it seems
> >>> like
> >>> > >> >> we should be
> >>> > >> >> > > >> >> just passing
> >>> > >> >> > > >> >> > > > > > > > JNIEnv as a parameter to all
> >>> functions in
> >>> > >> >> VM. Or, we can
> >>> > >> >> > > >> >> be taking it
> >>> > >> >> > > >> >> > > > > > > > from TLS (via jthread_self()), depending
> >>> > >> >> on which way is
> >>> > >> >> > > >> >> faster...
> >>> > >> >> > > >> >> > > > > > > Agree.
> >>> > >> >> > > >> >> > > > > > >
> >>> > >> >> > > >> >> > > > > > > >
> >>> > >> >> > > >> >> > > > > > > > >
> >>> > >> >> > > >> >> > > > > > > > > >
> >>> > >> >> > > >> >> > > > > > > > > > 6). And small remarks:
> >>> > >> >> > > >> >> > > > > > > > > > +jint vm_init1(JavaVM_Internal *
> >>> > >> java_vm,
> >>> > >> >> > > >> >> JavaVMInitArgs * vm_arguments);
> >>> > >> >> > > >> >> > > > > > > > > > +jint vm_init2(JNIEnv_Internal *
> >>> > >> >> jni_env);
> >>> > >> >> > > >> >> > > > > > > > > > Could you make names more
> >>> meaningful,
> >>> > >> >> then 1,2,3...?
> >>> > >> >> > > >> >> > > > > > > > > Ok, will do that.
> >>> > >> >> > > >> >> > > > > > > > >
> >>> > >> >> > > >> >> > > > > > > > > >
> >>> > >> >> > > >> >> > > > > > > > > > class VM_thread {
> >>> > >> >> > > >> >> > > > > > > > > > ...
> >>> > >> >> > > >> >> > > > > > > > > > + JNIEnv_Internal * jni_env;
> >>> > >> >> > > >> >> > > > > > > > > > The jthread already has the jni_env
> >>> > >> >> pointer, you do
> >>> > >> >> > > >> >> not need to
> >>> > >> >> > > >> >> > > > > > > > > > duplicate it here.
> >>> > >> >> > > >> >> > > > > > > > > > forexample by using
> >>> > >> >> > > >> >> jthread_get_JNI_env(jthread_self());
> >>> > >> >> > > >> >> > > > > > > > >
> >>> > >> >> > > >> >> > > > > > > > > Yes I know. I don't see any problems
> >>> > >> >> here. Some times
> >>> > >> >> > > >> >> it is much more
> >>> > >> >> > > >> >> > > > > > > > > convenient to get JNIEnv from
> >>> VM_thread
> >>> > >> >> structure (and
> >>> > >> >> > > >> >> faster) instead
> >>> > >> >> > > >> >> > > > > > > > > of doing jthread_get_JNI_env
> >>> > >> (jthread_self
> >>> > >> >> ()). So I
> >>> > >> >> > > >> >> need strong
> >>> > >> >> > > >> >> > > > > > > > > arguments for removing it. Again it
> >>> > >> >> seems that should
> >>> > >> >> > > >> >> be addressed in
> >>> > >> >> > > >> >> > > > > > > > > design of multi VM. So lets forget
> >>> about
> >>> > >> >> it for a
> >>> > >> >> > > >> >> while...
> >>> > >> >> > > >> >> > > > > > > >
> >>> > >> >> > > >> >> > > > > > > > I think that the data duplication would
> >>> > >> >> always serve as
> >>> > >> >> > > >> >> a potential
> >>> > >> >> > > >> >> > > > > > > > source of errors - while updating one
> >>> copy
> >>> > >> >> of object,
> >>> > >> >> > > >> >> you may forget
> >>> > >> >> > > >> >> > > > > > > > to update the other, often resulting
> >>> into
> >>> > >> >> a strange
> >>> > >> >> > > >> >> behavior of the
> >>> > >> >> > > >> >> > > > > > > > whole application. Let's see what are
> >>> the
> >>> > >> >> specific
> >>> > >> >> > > >> >> performance
> >>> > >> >> > > >> >> > > > > > > > concerns that have to be addressed.
> >>> To get
> >>> > >> >> VM_thread
> >>> > >> >> > > >> >> structure, you
> >>> > >> >> > > >> >> > > > > > > > would eventually go to the TLS, just
> >>> like
> >>> > >> >> > > >> >> > > > > > > > jthread_get_JNI_env(jthread_self()
> >>> > >> would do.
> >>> > >> >> > > >> >> > > > > > > If there is already VM_thread structure
> >>> for
> >>> > >> >> some reasons
> >>> > >> >> > > >> >> then there
> >>> > >> >> > > >> >> > > > > > > will be no extra access to TLS. It is
> >>> > >> >> definitely much
> >>> > >> >> > > >> more in
> >>> > >> >> > > >> >> > > > > > > jthread_get_JNI_env(jthread_self() than
> >>> just
> >>> > >> >> one TLS
> >>> > >> >> > > >> >> access and one
> >>> > >> >> > > >> >> > > > > > > dereferncing. I don't think it is a really
> >>> > >> >> big problem
> >>> > >> >> > > >> >> now. Do you
> >>> > >> >> > > >> >> > > > > > > agree to look at this later. I guess
> >>> > >> multi VM
> >>> > >> >> > > >> >> implementation will
> >>> > >> >> > > >> >> > > > > > > alter it in any case.
> >>> > >> >> > > >> >> > > > > > >
> >>> > >> >> > > >> >> > > > > > > Thanks
> >>> > >> >> > > >> >> > > > > > > Evgueni
> >>> > >> >> > > >> >> > > > > > >
> >>> > >> >> > > >> >> > > > > > > >
> >>> > >> >> > > >> >> > > > > > > > Thanks,
> >>> > >> >> > > >> >> > > > > > > > Andrey.
> >>> > >> >> > > >> >> > > > > > > >
> >>> > >> >> > > >> >> > > > > > > > >
> >>> > >> >> > > >> >> > > > > > > > > Evgueni
> >>> > >> >> > > >> >> > > > > > > > > >
> >>> > >> >> > > >> >> > > > > > > > > > Thanks
> >>> > >> >> > > >> >> > > > > > > > > > Artem
> >>> > >> >> > > >> >> > > > > > > > > >
> >>> > >> >> > > >> >> > > > > > > > > > On 9/28/06, Evgueni Brevnov
> >>> > >> >> > > >> >> <ev...@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.
> >>> > >> >> > > >> >> > > > > > > > > > >
> >>> > >> >> > > >> >> > > > > > > > > > > Thanks
> >>> > >> >> > > >> >> > > > > > > > > > > Evgueni
> >>> > >> >> > > >> >> > > > > > > > > > >
> >>> > >> >> > > >> >> > > > > > > > > > > On 9/28/06, Geir Magnusson Jr.
> >>> > >> >> <ge...@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
> >>> > >> >> > > >> >> <we...@gmail.com> wrote:
> >>> > >> >> > > >> >> > > > > > > > > > > > >> On 9/26/06, Evgueni Brevnov
> >>> > >> >> > > >> >> <ev...@gmail.com> wrote:
> >>> > >> >> > > >> >> > > > > > > > > > > > >> >
> >>> > >> >> > > >> >> > > > > > > > > > > > >> > On 9/27/06, Andrey
> >>> Chernyshev
> >>> > >> >> > > >> >> <a....@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
> >>> > >> >> > > >> >> > > > > > > > > > >
> >>> > >> >> > > >> >> > > > > > > > > > >
> >>> > >> >> > > >> >> > > > > > > > > >
> >>> > >> >> > > >> >> > > > > > > > > >
> >>> > >> >> > > >> >>
> >>> > >> >>
> >>> > >>
> >>> ---------------------------------------------------------------------
> >>> > >> >> > > >> >> > > > > > > > > > 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
> >>> > >> >> > > >> >> > > > > > > > >
> >>> > >> >> > > >> >> > > > > > > > >
> >>> > >> >> > > >> >> > > > > > > >
> >>> > >> >> > > >> >> > > > > > > >
> >>> > >> >> > > >> >> > > > > > > > --
> >>> > >> >> > > >> >> > > > > > > > Andrey Chernyshev
> >>> > >> >> > > >> >> > > > > > > > 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
> >>> > >> >> > > >> >> > > > > >
> >>> > >> >> > > >> >> > > > > >
> >>> > >> >> > > >> >> > > > >
> >>> > >> >> > > >> >> > > > >
> >>> > >> >> > > >> >> > > > > --
> >>> > >> >> > > >> >> > > > > Andrey Chernyshev
> >>> > >> >> > > >> >> > > > > 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
> >>> > >> >> > > >> >> > > >
> >>> > >> >> > > >> >> > > >
> >>> > >> >> > > >> >> > >
> >>> > >> >> > > >> >> > >
> >>> > >> >> > > >> >> > > --
> >>> > >> >> > > >> >> > > Andrey Chernyshev
> >>> > >> >> > > >> >> > > 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
> >>> > >> >> > > >>
> >>> > >> >> > > >>
> >>> > >> >> > > >
> >>> > >> >> > > >
> >>> > >> >>
> >>> > >>
> >>> ---------------------------------------------------------------------
> >>> > >> >> > > > 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
> >>> > >> >
> >>> > >>
> >>> > >>
> >>> > >>
> >>> ---------------------------------------------------------------------
> >>> > >> 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
> >>> >
> >>> >
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> 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
>
>
---------------------------------------------------------------------
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
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
that works. explain why
Evgueni Brevnov wrote:
> Could you insert sleep_a_click(); just before line 59 right after
> hysem_create(&start, 0, 1):
>
> Does it help?
>
> On 10/9/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>> [echo] ## Executing C unit test: test_ti_instrum
>> [exec] Result: 1
>> [echo] INFO: TEST test_jthread_get_all_threads start
>> [echo] ERROR: Assertion '(thread_count)==(i +
>> initial_thread_count)' failed at /home/geir/dev/apache/harmony/
>> enhanced/trunk/working_vm/vm/tes
>> ts/unit/thread/test_ti_instrum.c:94
>> [echo] Init1: initial_thread_count=1, initial_all_threads_count=1
>> [echo] Init3: initial_thread_count=1, initial_all_threads_count=1
>> [echo] Init3: thread_count=3, all_threads_count=3
>> [echo] INFO: TEST test_jthread_get_all_threads: FAILED
>> [echo] INFO: TEST test_jthread_get_thread_count start
>> [echo] Init1: initial_thread_count=3, initial_all_threads_count=3
>> [echo] INFO: TEST test_jthread_get_thread_count: PASSED
>> [echo] INFO: TEST test_jthread_get_blocked_count start
>> [echo] INFO: TEST test_jthread_get_blocked_count: PASSED
>> [echo] ## TEST FAILED
>>
>>
>> On Oct 9, 2006, at 12:35 AM, Evgueni Brevnov wrote:
>>
>> > I put debug printing into test_ti_instrum.c and attached it to JIRA.
>> > Could you run it on your machine and send me console output.
>> >
>> > Evgueni
>> >
>> > On 10/9/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>> >> I keep getting a failure when running the tests -
>> >>
>> >> test_jthread_get_all-threads failling the assertion at
>> >> test_ti_instrum.c:80
>> >>
>> >> geir
>> >>
>> >> On Oct 8, 2006, at 7:19 AM, Evgueni Brevnov wrote:
>> >>
>> >> > While running cunit on Linux it turned out one test case fails some
>> >> > time. The fix is in tests.final.2.patch.
>> >> >
>> >> > So the last versions to be committed:
>> >> > invocation_api.final.patch
>> >> > build.final.2.patch
>> >> > tests.final.2.patch
>> >> >
>> >> > Evgueni
>> >> >
>> >> >
>> >> > On 10/8/06, Evgueni Brevnov <ev...@gmail.com> wrote:
>> >> >> I mahaged to resolve the problem on Linux.... will update
>> >> >> build.final.patch with build.final.2.patch in a while
>> >> >>
>> >> >> On 10/8/06, Evgueni Brevnov <ev...@gmail.com> wrote:
>> >> >> > Hi,
>> >> >> >
>> >> >> > Oh! Ooh! I did that..... I passed cunit, somke, kernel tests on
>> >> >> > Windows and smoke, kernel tests on Linux. Unfortunately I
>> >> failed to
>> >> >> > link cunit tests on Linux so far. So I disabled cunit on Linux
>> >> >> until
>> >> >> > the problem is solved. I believe it is acceptable as short term
>> >> >> > solution. I found several problems in cunit tests. I will come
>> >> >> up with
>> >> >> > my findings later (not today).
>> >> >> >
>> >> >> > Use latest patches from HARMONY-1582. They are marked as final.
>> >> >> There
>> >> >> > are three patches. One for build module, one for cunit tests and
>> >> >> one
>> >> >> > for VM itself.
>> >> >> >
>> >> >> > Thanks
>> >> >> > Evgueni
>> >> >> >
>> >> >> >
>> >> >> > On 10/6/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>> >> >> > > Nooooooo! LOL
>> >> >> > >
>> >> >> > > I'm here waiting - This will unblock a whole bunch of
>> >> things :)
>> >> >> > >
>> >> >> > > Thanks for the effort
>> >> >> > >
>> >> >> > > Evgueni Brevnov wrote:
>> >> >> > > > Geir,
>> >> >> > > >
>> >> >> > > > That's terrible. We have power outage....servers are down. I
>> >> >> can't
>> >> >> > > > send the patches now.... will do it tomorrow
>> >> >> > > >
>> >> >> > > > Evgueni
>> >> >> > > > On 10/5/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>> >> >> > > >> woo hoo! here we go...
>> >> >> > > >>
>> >> >> > > >>
>> >> >> > > >> Andrey Chernyshev wrote:
>> >> >> > > >> > Hi Evgueni,
>> >> >> > > >> >
>> >> >> > > >> > On 10/4/06, Evgueni Brevnov <ev...@gmail.com>
>> >> >> wrote:
>> >> >> > > >> >> Hi All,
>> >> >> > > >> >>
>> >> >> > > >> >> I have attached updated patch to the JIRA. It should
>> >> >> resolve remain
>> >> >> > > >> >> concerns. Andrey, could you give a green light now?
>> >> >> > > >> >
>> >> >> > > >> > Thanks for updating the patch! I agree it it can be
>> >> >> committed, at
>> >> >> > > >> > least signatures look good. 5 revisions seem like more
>> >> >> than enough :).
>> >> >> > > >> > Anyways, I think the remaining issues can be resolved
>> >> >> with additional
>> >> >> > > >> > patches. Thanks again for the good work and your
>> >> patience.
>> >> >> > > >> >
>> >> >> > > >> > Thanks,
>> >> >> > > >> > Andrey.
>> >> >> > > >> >
>> >> >> > > >> >>
>> >> >> > > >> >> Thanks
>> >> >> > > >> >> Evgueni
>> >> >> > > >> >>
>> >> >> > > >> >> On 10/4/06, Evgueni Brevnov <ev...@gmail.com>
>> >> >> wrote:
>> >> >> > > >> >> > Andrey,
>> >> >> > > >> >> >
>> >> >> > > >> >> > I see your points. I think both approaches have
>> >> >> advantages and
>> >> >> > > >> >> > disadvantages. I think it is quite hard to say which
>> >> >> approach is
>> >> >> > > >> >> > better until we play with one VM only. I still feel
>> >> >> like introducing
>> >> >> > > >> >> > one more dependence is better than spreading code
>> >> >> which deals with
>> >> >> > > >> >> > attachment among VM and TM. We really get stuck. OK,
>> >> >> just because I
>> >> >> > > >> >> > want to move forward I will do required changes to
>> >> remove
>> >> >> > > >> >> > vm_create_jthread from TM. I believe that will resolve
>> >> >> all our
>> >> >> > > >> >> > disagreements and the patch will be applied soon.
>> >> >> > > >> >> >
>> >> >> > > >> >> >
>> >> >> > > >> >> > Thanks
>> >> >> > > >> >> > Evgueni.
>> >> >> > > >> >> >
>> >> >> > > >> >> > On 10/4/06, Andrey Chernyshev
>> >> >> <a....@gmail.com> wrote:
>> >> >> > > >> >> > > On 10/3/06, Evgueni Brevnov
>> >> >> <ev...@gmail.com> wrote:
>> >> >> > > >> >> > > > On 10/3/06, Andrey Chernyshev
>> >> >> <a....@gmail.com> wrote:
>> >> >> > > >> >> > > > > On 10/2/06, Evgueni Brevnov
>> >> >> <ev...@gmail.com> wrote:
>> >> >> > > >> >> > > > > > Andrey,
>> >> >> > > >> >> > > > > >
>> >> >> > > >> >> > > > > > Just to be clear.... I agree with you it is
>> >> more
>> >> >> > > >> convenient if
>> >> >> > > >> >> > > > > > jthread_create takes JNIEnv instead of
>> >> JavaVM. It
>> >> >> > > >> reflects that
>> >> >> > > >> >> > > > > > current thread has been attached already. Do
>> >> >> you think it
>> >> >> > > >> >> makes sense
>> >> >> > > >> >> > > > > > to get rid of JNIEnv and use
>> >> >> jthread_get_JNI_env in that
>> >> >> > > >> case?
>> >> >> > > >> >> > > > >
>> >> >> > > >> >> > > > > The jthread_* layer is designed like if it were
>> >> >> a regular JNI
>> >> >> > > >> >> > > > > application which is meant to be called from the
>> >> >> Java code,
>> >> >> > > >> hence
>> >> >> > > >> >> > > > > every function on that layer receives JNIenv. We
>> >> >> can probably
>> >> >> > > >> >> get rid
>> >> >> > > >> >> > > > > of the JNEnv parameter for jthread_* functions,
>> >> >> assuming that
>> >> >> > > >> >> TM can
>> >> >> > > >> >> > > > > always extract JNIenv for the current thread
>> >> with
>> >> >> > > >> >> > > > > jthread_get_JNI_env().
>> >> >> > > >> >> > > > > My only concern would be the performance - once
>> >> >> the JNIenv is
>> >> >> > > >> >> already
>> >> >> > > >> >> > > > > known for the native part of the kernel classes
>> >> >> impl, it
>> >> >> > > >> must be
>> >> >> > > >> >> > > > > cheaper to pass JNIEnv to TM as an extra
>> >> >> parameter rather than
>> >> >> > > >> >> extract
>> >> >> > > >> >> > > > > it from the TLS again.
>> >> >> > > >> >> > > > > Other than that, I see no strong advantages in
>> >> >> keeping JNIEnv
>> >> >> > > >> >> parameter.
>> >> >> > > >> >> > > > >
>> >> >> > > >> >> > > > >
>> >> >> > > >> >> > > > > > Regarding jthread_attach. I still didn't get
>> >> >> your point....
>> >> >> > > >> >> Clarify it
>> >> >> > > >> >> > > > > > please if you think jhread_attach should be
>> >> >> modified.
>> >> >> > > >> >> > > > >
>> >> >> > > >> >> > > > > Sorry for being not clear: I think for
>> >> >> jthread_attach, we have
>> >> >> > > >> >> two options:
>> >> >> > > >> >> > > > > 1) Make JNIEnv input parameter - it must be new
>> >> >> JNIEnv that VM
>> >> >> > > >> >> > > > > pre-allocates for the new Java thread.
>> >> >> jthread_attach
>> >> >> > > >> would just
>> >> >> > > >> >> > > > > associate it with the current thread.
>> >> >> > > >> >> > > > >
>> >> >> > > >> >> > > > > 2) Obtain JNIEnv via vm_attach() callback. In
>> >> >> this case, if
>> >> >> > > >> >> > > > > vm_attach() callback implementation needs to
>> >> >> know for which
>> >> >> > > >> >> JavaVM new
>> >> >> > > >> >> > > > > JNIenv has to be allocated, then we'll need to
>> >> >> add JavaVM as
>> >> >> > > >> >> input
>> >> >> > > >> >> > > > > parameter for jthread_attach().
>> >> >> > > >> >> > > > > I think both options should be fine, (1) would
>> >> >> probably
>> >> >> > > >> keep TM
>> >> >> > > >> >> > > > > interface a bit lighter, though (2) may look
>> >> >> more closer to
>> >> >> > > >> >> the JNI
>> >> >> > > >> >> > > > > invocation API idea.
>> >> >> > > >> >> > > > > So I think adding JavaVM specifically for
>> >> >> jthread_attach
>> >> >> > > >> may make
>> >> >> > > >> >> > > > > sense given the explanation you provided
>> >> earlier.
>> >> >> > > >> >> > > > >
>> >> >> > > >> >> > > > > The concern I would have regarding the proposed
>> >> >> jthread_attach
>> >> >> > > >> >> > > > > implementation is a call to vm_create_jthread()
>> >> >> - this call
>> >> >> > > >> >> introduces
>> >> >> > > >> >> > > > > an extra dependency of TM on vmcore that I'd
>> >> >> prefer to be
>> >> >> > > >> >> avoided. In
>> >> >> > > >> >> > > > > the original version, jthread_attach() was
>> >> >> taking jthread
>> >> >> > > >> >> argument of
>> >> >> > > >> >> > > > > the already prepared j.l.Thread.
>> >> >> > > >> >> > > >
>> >> >> > > >> >> > > > I understand your concern. Unfortunately I don't
>> >> >> see what we
>> >> >> > > >> can do
>> >> >> > > >> >> > > > here. Let me explain. In the beginning you have an
>> >> >> unattached
>> >> >> > > >> >> native
>> >> >> > > >> >> > > > thread. To be able to call java code (which is
>> >> >> required for
>> >> >> > > >> >> > > > constructing j.l.Thread instance) the thread
>> >> >> should be attached
>> >> >> > > >> >> first.
>> >> >> > > >> >> > > > To be specific it should be attached to VM by
>> >> >> calling vm_attach
>> >> >> > > >> >> which
>> >> >> > > >> >> > > > will return a valid JNIEnv It is valid to use JNI
>> >> >> from that
>> >> >> > > >> moment.
>> >> >> > > >> >> > > > Obtained JNIEnv can be used to execute java code
>> >> >> and create
>> >> >> > > >> >> j.l.Thread
>> >> >> > > >> >> > > > instance. Since we do vm_attach in jthread_attach
>> >> >> we need to do
>> >> >> > > >> >> > > > vm_create_jthread inside jthread_atach as well.
>> >> >> > > >> >> > > > Of course it can be an alternative to do vm_attach
>> >> >> and
>> >> >> > > >> >> > > > vm_create_jthread outside of TM right before
>> >> >> jthread_attach.
>> >> >> > > >> >> Sure it
>> >> >> > > >> >> > > > will reduce one dependence between VM and TM. But
>> >> >> it seems like
>> >> >> > > >> >> > > > artificial action for me just because of
>> >> >> dependency....
>> >> >> > > >> >> > >
>> >> >> > > >> >> > > Why do you think it is artificial? I would rather
>> >> >> prefer not to
>> >> >> > > >> throw
>> >> >> > > >> >> > > vm_attach event from the jthread_attach() call at
>> >> >> all than to add
>> >> >> > > >> >> > > extra dependency. The idea of jthread layer is a
>> >> >> Java face to
>> >> >> > > >> >> > > hythread, it is meant to know either a little or
>> >> >> nothing about the
>> >> >> > > >> >> > > rest of VM. It may be logical to throw vm_attach
>> >> >> call from the
>> >> >> > > >> newly
>> >> >> > > >> >> > > created thread, because there is no other way to let
>> >> >> know VM
>> >> >> > > >> the new
>> >> >> > > >> >> > > thread is created. VM attach is a different case -
>> >> >> VM already
>> >> >> > > >> knows
>> >> >> > > >> >> > > about new Java thread at the time of the
>> >> >> AttachCurrentThread call.
>> >> >> > > >> >> > >
>> >> >> > > >> >> > > >
>> >> >> > > >> >> > > > > Do you think it makes sense to replace a single
>> >> >> jthread
>> >> >> > > >> >> parameter with
>> >> >> > > >> >> > > > > a variety of stuff (like thread group, name)? It
>> >> >> seems the
>> >> >> > > >> only
>> >> >> > > >> >> > > > > purpose of at these args is to be passed back to
>> >> >> VM for
>> >> >> > > >> >> > > > > vm_jthread_create(). I would suggest to change
>> >> >> this and try
>> >> >> > > >> doing
>> >> >> > > >> >> > > > > either of:
>> >> >> > > >> >> > > > > 1) Make signature of jthread_attach with 3 args,
>> >> >> JavaVM,
>> >> >> > > >> >> jthread and the daemon.
>> >> >> > > >> >> > > > Why do you want to pass daemon to TM but thread's
>> >> >> name and
>> >> >> > > >> >> group. Just
>> >> >> > > >> >> > > > because current TM doesn't need such information?
>> >> >> What if it is
>> >> >> > > >> >> > > > required to get thread name later? Say by
>> >> introducing
>> >> >> > > >> >> > >
>> >> >> > > >> >> > > I imagine you need a daemon attribute since the TM
>> >> >> is still
>> >> >> > > >> managing
>> >> >> > > >> >> > > the thread daemonality. TM is not managing thread
>> >> >> name and group -
>> >> >> > > >> >> > > they are all kept on the Java level, hence passing
>> >> >> them may be
>> >> >> > > >> >> > > excessive.
>> >> >> > > >> >> > >
>> >> >> > > >> >> > > > jthread_get_name... What will you do in that case?
>> >> >> Let me
>> >> >> > > >> guess you
>> >> >> > > >> >> > > > will call j.l.Thread.getName. Right. Ok! In that
>> >> >> case I see no
>> >> >> > > >> >> > > > problems to call j.l.Thread.isDaemon. Do you
>> >> >> agree? So it
>> >> >> > > >> doesn't
>> >> >> > > >> >> > >
>> >> >> > > >> >> > > As I suggested earlier, the best way to handle
>> >> >> daemonality would
>> >> >> > > >> >> > > probably be in pure Java - in j.l.Thread (or
>> >> >> > > >> j.l.VMThreadManager) or
>> >> >> > > >> >> > > whatever. You already lifted it up to the jthread
>> >> >> level, but
>> >> >> > > >> what if
>> >> >> > > >> >> > > we can go a little bit higher...
>> >> >> > > >> >> > >
>> >> >> > > >> >> > > > seems to be a good design to pass only part of the
>> >> >> > > >> information to
>> >> >> > > >> >> > > > jthread_atach. Lets look at the signature of
>> >> >> > > >> >> AttachCurrentThread. It
>> >> >> > > >> >> > > > takes exactly these three parameters (daemon,
>> >> >> name, group)
>> >> >> > > >> >> passed as a
>> >> >> > > >> >> > > > structure. I was thinking about having exactly the
>> >> >> same
>> >> >> > > >> >> structure as
>> >> >> > > >> >> > > > third parameter of jthread_attach but it occured
>> >> >> to be more
>> >> >> > > >> >> convinient
>> >> >> > > >> >> > > > to pass them seperatly. Although I don't see
>> >> >> strong reasons
>> >> >> > > >> against
>> >> >> > > >> >> > > > having a structure a third parameter.
>> >> >> > > >> >> > >
>> >> >> > > >> >> > > I see. Acually, I would love to keep the
>> >> >> jthread_attach func-ty at
>> >> >> > > >> >> the
>> >> >> > > >> >> > > minimum level which will be needed to handle the
>> >> >> only data that TM
>> >> >> > > >> >> > > should be aware of. We need a formal boundary
>> >> >> between jthread
>> >> >> > > >> layer
>> >> >> > > >> >> > > and vmcore (otherwise jthread won't have a much of
>> >> >> sense, one may
>> >> >> > > >> >> > > consider it just as a convenience set of functions
>> >> >> in vmcore which
>> >> >> > > >> >> are
>> >> >> > > >> >> > > doing something with threading).
>> >> >> > > >> >> > >
>> >> >> > > >> >> > > >
>> >> >> > > >> >> > > > > 2) Move the implementation of vm_create_jtrhead
>> >> >> () to
>> >> >> > > >> >> > > > > thread_java_basic.c - could it be written in
>> >> >> pure JNI without
>> >> >> > > >> >> using
>> >> >> > > >> >> > > > > internal VM API like class_alloc_new_object()?
>> >> >> > > >> >> > > >
>> >> >> > > >> >> > > > Yes, this can be done but it doesn't fix the
>> >> >> problem. You still
>> >> >> > > >> >> need
>> >> >> > > >> >> > > > to know about internal constructor of j.l.Thread
>> >> >> > > >> >> > >
>> >> >> > > >> >> > > That's bad. Given what you said, now it seems that
>> >> >> the most
>> >> >> > > >> >> preferable
>> >> >> > > >> >> > > sequence for AttachCurrentThread impl still would be
>> >> >> like:
>> >> >> > > >> >> > > JNIEnv = vm_attach();
>> >> >> > > >> >> > > jthread = create_jthread(JNIenv)
>> >> >> > > >> >> > > jthread_attach(JNIEnv, jthread) // stores JNIEnv and
>> >> >> Hythread into
>> >> >> > > >> >> > > TLS, doesn't call vm_attach any longer.
>> >> >> > > >> >> > > - this is almost what we had from the beginning...
>> >> >> > > >> >> > >
>> >> >> > > >> >> > > Thanks,
>> >> >> > > >> >> > > Andrey.
>> >> >> > > >> >> > >
>> >> >> > > >> >> > > >
>> >> >> > > >> >> > > >
>> >> >> > > >> >> > > > Thanks
>> >> >> > > >> >> > > > Evgueni
>> >> >> > > >> >> > > > >
>> >> >> > > >> >> > > > >
>> >> >> > > >> >> > > > > Thanks,
>> >> >> > > >> >> > > > > Andrey.
>> >> >> > > >> >> > > > >
>> >> >> > > >> >> > > > > >
>> >> >> > > >> >> > > > > > Thank you
>> >> >> > > >> >> > > > > > Evgueni
>> >> >> > > >> >> > > > > >
>> >> >> > > >> >> > > > > > On 10/2/06, Evgueni Brevnov
>> >> >> <ev...@gmail.com>
>> >> >> > > >> wrote:
>> >> >> > > >> >> > > > > > > On 9/29/06, Andrey Chernyshev
>> >> >> <a....@gmail.com>
>> >> >> > > >> >> wrote:
>> >> >> > > >> >> > > > > > > > On 9/29/06, Evgueni Brevnov
>> >> >> <ev...@gmail.com>
>> >> >> > > >> >> wrote:
>> >> >> > > >> >> > > > > > > > > Artem,
>> >> >> > > >> >> > > > > > > > >
>> >> >> > > >> >> > > > > > > > > Thank you for your feedback.... find my
>> >> >> inlined.....
>> >> >> > > >> >> > > > > > > > >
>> >> >> > > >> >> > > > > > > > > On 9/29/06, Artem Aliev
>> >> >> <ar...@gmail.com> wrote:
>> >> >> > > >> >> > > > > > > > > > Evgueni,
>> >> >> > > >> >> > > > > > > > > >
>> >> >> > > >> >> > > > > > > > > > I got most of your changes, but still
>> >> >> disagree
>> >> >> > > >> with all
>> >> >> > > >> >> > > > > > > > > > hythread/jthread interface changes.
>> >> >> Could leave
>> >> >> > > >> >> interface unchanged.
>> >> >> > > >> >> > > > > > > > > > See following possible solutions, that
>> >> >> could solve
>> >> >> > > >> >> the same problems
>> >> >> > > >> >> > > > > > > > > > without interface changes.
>> >> >> > > >> >> > > > > > > > > >
>> >> >> > > >> >> > > > > > > > > >
>> >> >> > > >> >> > > > > > > > > > 1) daemon attribute is a java
>> >> >> specific. (Andrey
>> >> >> > > >> >> mentioned this already).
>> >> >> > > >> >> > > > > > > > > > Could you please move it back. to
>> >> >> the jthread
>> >> >> > > >> >> layer. It is better
>> >> >> > > >> >> > > > > > > > > > to rename
>> >> >> > > >> >> > > > > > > > > >
>> >> >> hythread_wait_for_all_nondaemon_threads() to
>> >> >> > > >> >> > > > > > > > > >
>> >> jthread_wait_for_all_nondaemon_threads().
>> >> >> > > >> >> > > > > > > > > Ok, I see no problems to move "daemon"
>> >> >> to java layer.
>> >> >> > > >> >> In that case:
>> >> >> > > >> >> > > > > > > > > 1) I will move
>> >> >> > > >> >> hythread_wait_for_all_nondaemon_threads() from
>> >> >> > > >> >> > > > > > > > > thread_init.c to one which implements
>> >> >> java layer.
>> >> >> > > >> >> > > > > > > > > 2) I will move daemon field from
>> >> >> HyThread structure.
>> >> >> > > >> >> > > > > > > > >
>> >> >> > > >> >> > > > > > > > > Agree?
>> >> >> > > >> >> > > > > > > >
>> >> >> > > >> >> > > > > > > > Sounds good to me.
>> >> >> > > >> >> > > > > > >
>> >> >> > > >> >> > > > > > > OK, will do that.
>> >> >> > > >> >> > > > > > >
>> >> >> > > >> >> > > > > > > >
>> >> >> > > >> >> > > > > > > >
>> >> >> > > >> >> > > > > > > > >
>> >> >> > > >> >> > > > > > > > > >
>> >> >> > > >> >> > > > > > > > > > 2) JavaVM could be retrieved from
>> >> >> JNIEnv by
>> >> >> > > >> >> jni_get_java_vm(). So
>> >> >> > > >> >> > > > > > > > > > let the jthread_create() and others to
>> >> >> use JNIEnv
>> >> >> > > >> >> (that is passed from
>> >> >> > > >> >> > > > > > > > > > java native method).
>> >> >> > > >> >> > > > > > > > > > The vm_attach could get old JNI env
>> >> >> and create new
>> >> >> > > >> >> one for the new thread.
>> >> >> > > >> >> > > > > > > > > > The first JNIEnv is created in
>> >> >> CreateVM call and
>> >> >> > > >> >> could be passed to
>> >> >> > > >> >> > > > > > > > > > the first thread at startup.
>> >> >> > > >> >> > > > > > > > > No, no, no. I completely disagree with
>> >> >> that!!! Why do
>> >> >> > > >> >> you like JNIEnv
>> >> >> > > >> >> > > > > > > > > but JavaVM. Why do you think that
>> >> >> passing JavaVM
>> >> >> > > >> >> instead of JNIEnv
>> >> >> > > >> >> > > > > > > > > makes TM less modular? I don't see any
>> >> >> difference
>> >> >> > > >> >> here.... It seems
>> >> >> > > >> >> > > > > > > > > for me like a big big hack to grab
>> >> >> JNIEnv from another
>> >> >> > > >> >> thread and pass
>> >> >> > > >> >> > > > > > > > > it to jthread_attach to perform
>> >> >> operations in the
>> >> >> > > >> >> current thread.
>> >> >> > > >> >> > > > > > > >
>> >> >> > > >> >> > > > > > > > TM needs to know JNIEnv, mainly for
>> >> >> managing the
>> >> >> > > >> >> references to
>> >> >> > > >> >> > > > > > > > objects, throwing exceptions and calling
>> >> >> run() method of
>> >> >> > > >> >> a new thread.
>> >> >> > > >> >> > > > > > > > JNI spec proposes that JNIEnv is valid
>> >> >> within the given
>> >> >> > > >> >> thread, this
>> >> >> > > >> >> > > > > > > > is why TM holds the JNIEnv pointer at the
>> >> >> moment. This
>> >> >> > > >> >> is why TM likes
>> >> >> > > >> >> > > > > > > > the JNIEnv.
>> >> >> > > >> >> > > > > > > >
>> >> >> > > >> >> > > > > > > > Having the JNIEnv, one is able to get
>> >> >> JavaVM but not
>> >> >> > > >> >> vise versa. This
>> >> >> > > >> >> > > > > > > > is why TM doesn't like the JavaVM :)
>> >> >> > > >> >> > > > > > > I see your point. Only one note this is true
>> >> >> for already
>> >> >> > > >> >> attached threads...
>> >> >> > > >> >> > > > > > >
>> >> >> > > >> >> > > > > > > >
>> >> >> > > >> >> > > > > > > > I agree with you that there is a design
>> >> >> flaw that the
>> >> >> > > >> >> JNIEnv is copied
>> >> >> > > >> >> > > > > > > > from the parent thread to a child thread
>> >> >> during thread
>> >> >> > > >> >> creation. I
>> >> >> > > >> >> > > > > > > > think it could be resolved via vm_attach()
>> >> >> hook - with
>> >> >> > > >> >> this event, VM
>> >> >> > > >> >> > > > > > > > might tell the TM what the JNIEnv pointer
>> >> >> for new thread
>> >> >> > > >> >> should be. I
>> >> >> > > >> >> > > > > > > > think you did that by extending the
>> >> >> vm_attach() call
>> >> >> > > >> >> with the JNIEnv**
>> >> >> > > >> >> > > > > > > > argument.
>> >> >> > > >> >> > > > > > > >
>> >> >> > > >> >> > > > > > > > What is not completely clear is, why do
>> >> >> you have to pass
>> >> >> > > >> >> the JavaVM
>> >> >> > > >> >> > > > > > > > forth and back, once from VM to TM, and
>> >> >> then back from
>> >> >> > > >> >> TM to VM again?
>> >> >> > > >> >> > > > > > > >
>> >> >> > > >> >> > > > > > > > If you need to know in jthread_attach,
>> >> >> which particular
>> >> >> > > >> >> VM vm_attach()
>> >> >> > > >> >> > > > > > > > event is coming from, you could have
>> >> >> vm_attach like
>> >> >> > > >> >> > > > > > > > vm_attach(JNIEnv* currentThreadEnv,
>> >> JNIEnv**
>> >> >> > > >> >> newThreadEnv).
>> >> >> > > >> >> > > > > > > I'm a little bit confused.....Current thread
>> >> >> hasn't been
>> >> >> > > >> >> attached yet.
>> >> >> > > >> >> > > > > > > So there is no JNIEnv for it yet. How it can
>> >> >> be passed as
>> >> >> > > >> >> the first
>> >> >> > > >> >> > > > > > > parameter to vm_attach()?
>> >> >> > > >> >> > > > > > >
>> >> >> > > >> >> > > > > > > > Then you will be always able to get the
>> >> >> JavaVM from the
>> >> >> > > >> >> JNIEnv.
>> >> >> > > >> >> > > > > > > > The only difference is that you are
>> >> >> currently doing
>> >> >> > > >> >> JNIEnv->JavaVM
>> >> >> > > >> >> > > > > > > > conversion in the VMThreadManager, but why
>> >> >> can't you
>> >> >> > > >> >> just do this in
>> >> >> > > >> >> > > > > > > > vm_attach() without changing the interface
>> >> >> of the TM?
>> >> >> > > >> >> > > > > > > > So far JavaVM really looks like an extra
>> >> >> knowledge that
>> >> >> > > >> >> TM doesn't
>> >> >> > > >> >> > > > > > > > have to be aware of.
>> >> >> > > >> >> > > > > > > >
>> >> >> > > >> >> > > > > > > > > Moreover there is no JNIEnv when main
>> >> >> thread attaches
>> >> >> > > >> >> to VM. So we
>> >> >> > > >> >> > > > > > > > > should either keep it as is or change
>> >> >> original design
>> >> >> > > >> >> of TM and attach
>> >> >> > > >> >> > > > > > > > > thread to VM before attaching it to TM.
>> >> >> In that case
>> >> >> > > >> >> we will have
>> >> >> > > >> >> > > > > > > > > valid JNIEnv which can be passed to
>> >> >> jthread_atatch. We
>> >> >> > > >> >> need to think
>> >> >> > > >> >> > > > > > > > > over it twice before changing
>> >> something....
>> >> >> > > >> >> > > > > > > >
>> >> >> > > >> >> > > > > > > > Right. For jthread_attach, JNIenv needs to
>> >> >> be changed
>> >> >> > > >> >> from being input
>> >> >> > > >> >> > > > > > > > parameter to being the output parameter.
>> >> >> The way how
>> >> >> > > >> >> JNIenv is
>> >> >> > > >> >> > > > > > > > obtained by TM should be vm_attach()
>> >> event.
>> >> >> > > >> >> > > > > > > OK, JNIEnv is output parameter. And it
>> >> >> obtained by
>> >> >> > > >> >> vm_attach(). This
>> >> >> > > >> >> > > > > > > is exactly like I do in the patch. What I
>> >> >> don't understand
>> >> >> > > >> >> is how
>> >> >> > > >> >> > > > > > > jthread_attach knows to which VM the thread
>> >> >> should be
>> >> >> > > >> >> attached? Do you
>> >> >> > > >> >> > > > > > > suggest calling vm_attach first to create
>> >> >> JNIEnv it pass
>> >> >> > > >> >> it to
>> >> >> > > >> >> > > > > > > jthread_attach?
>> >> >> > > >> >> > > > > > >
>> >> >> > > >> >> > > > > > > >
>> >> >> > > >> >> > > > > > > > >
>> >> >> > > >> >> > > > > > > > >
>> >> >> > > >> >> > > > > > > > >
>> >> >> > > >> >> > > > > > > > > >
>> >> >> > > >> >> > > > > > > > > >
>> >> >> > > >> >> > > > > > > > > > 4) Original classlib hythread do
>> >> not use
>> >> >> > > >> >> hythread_library_t in arguments,
>> >> >> > > >> >> > > > > > > > > > It uses following code:
>> >> >> > > >> >> > > > > > > > > >
>> >> >> > > >> >> > > > > > > > > > hythread_library_t lib = GLOBAL_DATA
>> >> >> > > >> >> (default_library);
>> >> >> > > >> >> > > > > > > > > > or
>> >> >> > > >> >> > > > > > > > > > hythread_library_t library = thread-
>> >> >> >library;
>> >> >> > > >> >> > > > > > > > > >
>> >> >> > > >> >> > > > > > > > > > So could you please use the same
>> >> >> mechanism and
>> >> >> > > >> >> remove hythread_*_ex >functions.
>> >> >> > > >> >> > > > > > > > > Let's see if classlib's hythread needs
>> >> >> changing first.
>> >> >> > > >> >> It seems for me
>> >> >> > > >> >> > > > > > > > > such code prevents us from having
>> >> multi VM.
>> >> >> > > >> >> > > > > > > > >
>> >> >> > > >> >> > > > > > > > > >
>> >> >> > > >> >> > > > > > > > > > 5. You introduce more then one jni
>> >> >> env, but still
>> >> >> > > >> >> use global variable for it.
>> >> >> > > >> >> > > > > > > > > > So all changes like following:
>> >> >> > > >> >> > > > > > > > > > - JNIEnv *jenv = (JNIEnv*)
>> >> >> jni_native_intf;
>> >> >> > > >> >> > > > > > > > > > + JNIEnv *jenv = jni_native_intf;
>> >> >> > > >> >> > > > > > > > > >
>> >> >> > > >> >> > > > > > > > > > should be like:
>> >> >> > > >> >> > > > > > > > > > - JNIEnv *jenv = (JNIEnv*)
>> >> >> jni_native_intf;
>> >> >> > > >> >> > > > > > > > > > + JNIEnv *jenv = get_jni_env
>> >> >> (jthread_self());
>> >> >> > > >> >> > > > > > > > >
>> >> >> > > >> >> > > > > > > > > Ok, I see. I agree that global
>> >> >> jni_native_intf should
>> >> >> > > >> >> not be used.
>> >> >> > > >> >> > > > > > > > > There was simple reason why I altered
>> >> >> such lines.
>> >> >> > > >> >> Because I changed
>> >> >> > > >> >> > > > > > > > > the type of jni_native_intf and no
>> >> >> casting operator
>> >> >> > > >> >> is needed now. To
>> >> >> > > >> >> > > > > > > > > be honest I think get_jni_env
>> >> >> (jthread_self()) can be
>> >> >> > > >> >> good as temporary
>> >> >> > > >> >> > > > > > > > > solution only. Lets wait for design of
>> >> >> multi VM and
>> >> >> > > >> >> fix it according
>> >> >> > > >> >> > > > > > > > > to it.
>> >> >> > > >> >> > > > > > > >
>> >> >> > > >> >> > > > > > > > While we are in JNI code, we always have
>> >> >> the JNIenv (at
>> >> >> > > >> >> least
>> >> >> > > >> >> > > > > > > > initially it comes from Java code). If we
>> >> >> consider VM
>> >> >> > > >> >> code as if it
>> >> >> > > >> >> > > > > > > > was a JNI application, then it seems like
>> >> >> we should be
>> >> >> > > >> >> just passing
>> >> >> > > >> >> > > > > > > > JNIEnv as a parameter to all functions in
>> >> >> VM. Or, we can
>> >> >> > > >> >> be taking it
>> >> >> > > >> >> > > > > > > > from TLS (via jthread_self()), depending
>> >> >> on which way is
>> >> >> > > >> >> faster...
>> >> >> > > >> >> > > > > > > Agree.
>> >> >> > > >> >> > > > > > >
>> >> >> > > >> >> > > > > > > >
>> >> >> > > >> >> > > > > > > > >
>> >> >> > > >> >> > > > > > > > > >
>> >> >> > > >> >> > > > > > > > > > 6). And small remarks:
>> >> >> > > >> >> > > > > > > > > > +jint vm_init1(JavaVM_Internal *
>> >> java_vm,
>> >> >> > > >> >> JavaVMInitArgs * vm_arguments);
>> >> >> > > >> >> > > > > > > > > > +jint vm_init2(JNIEnv_Internal *
>> >> >> jni_env);
>> >> >> > > >> >> > > > > > > > > > Could you make names more meaningful,
>> >> >> then 1,2,3...?
>> >> >> > > >> >> > > > > > > > > Ok, will do that.
>> >> >> > > >> >> > > > > > > > >
>> >> >> > > >> >> > > > > > > > > >
>> >> >> > > >> >> > > > > > > > > > class VM_thread {
>> >> >> > > >> >> > > > > > > > > > ...
>> >> >> > > >> >> > > > > > > > > > + JNIEnv_Internal * jni_env;
>> >> >> > > >> >> > > > > > > > > > The jthread already has the jni_env
>> >> >> pointer, you do
>> >> >> > > >> >> not need to
>> >> >> > > >> >> > > > > > > > > > duplicate it here.
>> >> >> > > >> >> > > > > > > > > > forexample by using
>> >> >> > > >> >> jthread_get_JNI_env(jthread_self());
>> >> >> > > >> >> > > > > > > > >
>> >> >> > > >> >> > > > > > > > > Yes I know. I don't see any problems
>> >> >> here. Some times
>> >> >> > > >> >> it is much more
>> >> >> > > >> >> > > > > > > > > convenient to get JNIEnv from VM_thread
>> >> >> structure (and
>> >> >> > > >> >> faster) instead
>> >> >> > > >> >> > > > > > > > > of doing jthread_get_JNI_env
>> >> (jthread_self
>> >> >> ()). So I
>> >> >> > > >> >> need strong
>> >> >> > > >> >> > > > > > > > > arguments for removing it. Again it
>> >> >> seems that should
>> >> >> > > >> >> be addressed in
>> >> >> > > >> >> > > > > > > > > design of multi VM. So lets forget about
>> >> >> it for a
>> >> >> > > >> >> while...
>> >> >> > > >> >> > > > > > > >
>> >> >> > > >> >> > > > > > > > I think that the data duplication would
>> >> >> always serve as
>> >> >> > > >> >> a potential
>> >> >> > > >> >> > > > > > > > source of errors - while updating one copy
>> >> >> of object,
>> >> >> > > >> >> you may forget
>> >> >> > > >> >> > > > > > > > to update the other, often resulting into
>> >> >> a strange
>> >> >> > > >> >> behavior of the
>> >> >> > > >> >> > > > > > > > whole application. Let's see what are the
>> >> >> specific
>> >> >> > > >> >> performance
>> >> >> > > >> >> > > > > > > > concerns that have to be addressed. To get
>> >> >> VM_thread
>> >> >> > > >> >> structure, you
>> >> >> > > >> >> > > > > > > > would eventually go to the TLS, just like
>> >> >> > > >> >> > > > > > > > jthread_get_JNI_env(jthread_self()
>> >> would do.
>> >> >> > > >> >> > > > > > > If there is already VM_thread structure for
>> >> >> some reasons
>> >> >> > > >> >> then there
>> >> >> > > >> >> > > > > > > will be no extra access to TLS. It is
>> >> >> definitely much
>> >> >> > > >> more in
>> >> >> > > >> >> > > > > > > jthread_get_JNI_env(jthread_self() than just
>> >> >> one TLS
>> >> >> > > >> >> access and one
>> >> >> > > >> >> > > > > > > dereferncing. I don't think it is a really
>> >> >> big problem
>> >> >> > > >> >> now. Do you
>> >> >> > > >> >> > > > > > > agree to look at this later. I guess
>> >> multi VM
>> >> >> > > >> >> implementation will
>> >> >> > > >> >> > > > > > > alter it in any case.
>> >> >> > > >> >> > > > > > >
>> >> >> > > >> >> > > > > > > Thanks
>> >> >> > > >> >> > > > > > > Evgueni
>> >> >> > > >> >> > > > > > >
>> >> >> > > >> >> > > > > > > >
>> >> >> > > >> >> > > > > > > > Thanks,
>> >> >> > > >> >> > > > > > > > Andrey.
>> >> >> > > >> >> > > > > > > >
>> >> >> > > >> >> > > > > > > > >
>> >> >> > > >> >> > > > > > > > > Evgueni
>> >> >> > > >> >> > > > > > > > > >
>> >> >> > > >> >> > > > > > > > > > Thanks
>> >> >> > > >> >> > > > > > > > > > Artem
>> >> >> > > >> >> > > > > > > > > >
>> >> >> > > >> >> > > > > > > > > > On 9/28/06, Evgueni Brevnov
>> >> >> > > >> >> <ev...@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.
>> >> >> > > >> >> > > > > > > > > > >
>> >> >> > > >> >> > > > > > > > > > > Thanks
>> >> >> > > >> >> > > > > > > > > > > Evgueni
>> >> >> > > >> >> > > > > > > > > > >
>> >> >> > > >> >> > > > > > > > > > > On 9/28/06, Geir Magnusson Jr.
>> >> >> <ge...@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
>> >> >> > > >> >> <we...@gmail.com> wrote:
>> >> >> > > >> >> > > > > > > > > > > > >> On 9/26/06, Evgueni Brevnov
>> >> >> > > >> >> <ev...@gmail.com> wrote:
>> >> >> > > >> >> > > > > > > > > > > > >> >
>> >> >> > > >> >> > > > > > > > > > > > >> > On 9/27/06, Andrey Chernyshev
>> >> >> > > >> >> <a....@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
>> >> >> > > >> >> > > > > > > > > > >
>> >> >> > > >> >> > > > > > > > > > >
>> >> >> > > >> >> > > > > > > > > >
>> >> >> > > >> >> > > > > > > > > >
>> >> >> > > >> >>
>> >> >>
>> >> ---------------------------------------------------------------------
>> >> >> > > >> >> > > > > > > > > > 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
>> >> >> > > >> >> > > > > > > > >
>> >> >> > > >> >> > > > > > > > >
>> >> >> > > >> >> > > > > > > >
>> >> >> > > >> >> > > > > > > >
>> >> >> > > >> >> > > > > > > > --
>> >> >> > > >> >> > > > > > > > Andrey Chernyshev
>> >> >> > > >> >> > > > > > > > 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
>> >> >> > > >> >> > > > > >
>> >> >> > > >> >> > > > > >
>> >> >> > > >> >> > > > >
>> >> >> > > >> >> > > > >
>> >> >> > > >> >> > > > > --
>> >> >> > > >> >> > > > > Andrey Chernyshev
>> >> >> > > >> >> > > > > 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
>> >> >> > > >> >> > > >
>> >> >> > > >> >> > > >
>> >> >> > > >> >> > >
>> >> >> > > >> >> > >
>> >> >> > > >> >> > > --
>> >> >> > > >> >> > > Andrey Chernyshev
>> >> >> > > >> >> > > 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
>> >> >> > > >>
>> >> >> > > >>
>> >> >> > > >
>> >> >> > > >
>> >> >>
>> >> ---------------------------------------------------------------------
>> >> >> > > > 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
>> >> >
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> 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
>>
>>
>
> ---------------------------------------------------------------------
> 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
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
Posted by Evgueni Brevnov <ev...@gmail.com>.
at least cunit tests instabilities should not prevent the patch
submission. It can take significant time to make them pass on
different configurations.....
Evgueni
On 10/9/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> Geir, Salikh,
>
> cunit tests are very unstable...... that's why we have different
> results on different platforms. It all tests problems. I already fixed
> several places but it seems there is much more left. I believe we need
> to revise them all. The main problem is that sleep(somthing) is used
> to synchronize different threads. Sometimes there is no synchraniztion
> at all. I propouse for switching it off until they get stable.
> Can we do it?
>
> Evgueni
>
> On 10/9/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> > Could you insert sleep_a_click(); just before line 59 right after
> > hysem_create(&start, 0, 1):
> >
> > Does it help?
> >
> > On 10/9/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> > > [echo] ## Executing C unit test: test_ti_instrum
> > > [exec] Result: 1
> > > [echo] INFO: TEST test_jthread_get_all_threads start
> > > [echo] ERROR: Assertion '(thread_count)==(i +
> > > initial_thread_count)' failed at /home/geir/dev/apache/harmony/
> > > enhanced/trunk/working_vm/vm/tes
> > > ts/unit/thread/test_ti_instrum.c:94
> > > [echo] Init1: initial_thread_count=1, initial_all_threads_count=1
> > > [echo] Init3: initial_thread_count=1, initial_all_threads_count=1
> > > [echo] Init3: thread_count=3, all_threads_count=3
> > > [echo] INFO: TEST test_jthread_get_all_threads: FAILED
> > > [echo] INFO: TEST test_jthread_get_thread_count start
> > > [echo] Init1: initial_thread_count=3, initial_all_threads_count=3
> > > [echo] INFO: TEST test_jthread_get_thread_count: PASSED
> > > [echo] INFO: TEST test_jthread_get_blocked_count start
> > > [echo] INFO: TEST test_jthread_get_blocked_count: PASSED
> > > [echo] ## TEST FAILED
> > >
> > >
> > > On Oct 9, 2006, at 12:35 AM, Evgueni Brevnov wrote:
> > >
> > > > I put debug printing into test_ti_instrum.c and attached it to JIRA.
> > > > Could you run it on your machine and send me console output.
> > > >
> > > > Evgueni
> > > >
> > > > On 10/9/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> > > >> I keep getting a failure when running the tests -
> > > >>
> > > >> test_jthread_get_all-threads failling the assertion at
> > > >> test_ti_instrum.c:80
> > > >>
> > > >> geir
> > > >>
> > > >> On Oct 8, 2006, at 7:19 AM, Evgueni Brevnov wrote:
> > > >>
> > > >> > While running cunit on Linux it turned out one test case fails some
> > > >> > time. The fix is in tests.final.2.patch.
> > > >> >
> > > >> > So the last versions to be committed:
> > > >> > invocation_api.final.patch
> > > >> > build.final.2.patch
> > > >> > tests.final.2.patch
> > > >> >
> > > >> > Evgueni
> > > >> >
> > > >> >
> > > >> > On 10/8/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> > > >> >> I mahaged to resolve the problem on Linux.... will update
> > > >> >> build.final.patch with build.final.2.patch in a while
> > > >> >>
> > > >> >> On 10/8/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> > > >> >> > Hi,
> > > >> >> >
> > > >> >> > Oh! Ooh! I did that..... I passed cunit, somke, kernel tests on
> > > >> >> > Windows and smoke, kernel tests on Linux. Unfortunately I
> > > >> failed to
> > > >> >> > link cunit tests on Linux so far. So I disabled cunit on Linux
> > > >> >> until
> > > >> >> > the problem is solved. I believe it is acceptable as short term
> > > >> >> > solution. I found several problems in cunit tests. I will come
> > > >> >> up with
> > > >> >> > my findings later (not today).
> > > >> >> >
> > > >> >> > Use latest patches from HARMONY-1582. They are marked as final.
> > > >> >> There
> > > >> >> > are three patches. One for build module, one for cunit tests and
> > > >> >> one
> > > >> >> > for VM itself.
> > > >> >> >
> > > >> >> > Thanks
> > > >> >> > Evgueni
> > > >> >> >
> > > >> >> >
> > > >> >> > On 10/6/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> > > >> >> > > Nooooooo! LOL
> > > >> >> > >
> > > >> >> > > I'm here waiting - This will unblock a whole bunch of
> > > >> things :)
> > > >> >> > >
> > > >> >> > > Thanks for the effort
> > > >> >> > >
> > > >> >> > > Evgueni Brevnov wrote:
> > > >> >> > > > Geir,
> > > >> >> > > >
> > > >> >> > > > That's terrible. We have power outage....servers are down. I
> > > >> >> can't
> > > >> >> > > > send the patches now.... will do it tomorrow
> > > >> >> > > >
> > > >> >> > > > Evgueni
> > > >> >> > > > On 10/5/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> > > >> >> > > >> woo hoo! here we go...
> > > >> >> > > >>
> > > >> >> > > >>
> > > >> >> > > >> Andrey Chernyshev wrote:
> > > >> >> > > >> > Hi Evgueni,
> > > >> >> > > >> >
> > > >> >> > > >> > On 10/4/06, Evgueni Brevnov <ev...@gmail.com>
> > > >> >> wrote:
> > > >> >> > > >> >> Hi All,
> > > >> >> > > >> >>
> > > >> >> > > >> >> I have attached updated patch to the JIRA. It should
> > > >> >> resolve remain
> > > >> >> > > >> >> concerns. Andrey, could you give a green light now?
> > > >> >> > > >> >
> > > >> >> > > >> > Thanks for updating the patch! I agree it it can be
> > > >> >> committed, at
> > > >> >> > > >> > least signatures look good. 5 revisions seem like more
> > > >> >> than enough :).
> > > >> >> > > >> > Anyways, I think the remaining issues can be resolved
> > > >> >> with additional
> > > >> >> > > >> > patches. Thanks again for the good work and your
> > > >> patience.
> > > >> >> > > >> >
> > > >> >> > > >> > Thanks,
> > > >> >> > > >> > Andrey.
> > > >> >> > > >> >
> > > >> >> > > >> >>
> > > >> >> > > >> >> Thanks
> > > >> >> > > >> >> Evgueni
> > > >> >> > > >> >>
> > > >> >> > > >> >> On 10/4/06, Evgueni Brevnov <ev...@gmail.com>
> > > >> >> wrote:
> > > >> >> > > >> >> > Andrey,
> > > >> >> > > >> >> >
> > > >> >> > > >> >> > I see your points. I think both approaches have
> > > >> >> advantages and
> > > >> >> > > >> >> > disadvantages. I think it is quite hard to say which
> > > >> >> approach is
> > > >> >> > > >> >> > better until we play with one VM only. I still feel
> > > >> >> like introducing
> > > >> >> > > >> >> > one more dependence is better than spreading code
> > > >> >> which deals with
> > > >> >> > > >> >> > attachment among VM and TM. We really get stuck. OK,
> > > >> >> just because I
> > > >> >> > > >> >> > want to move forward I will do required changes to
> > > >> remove
> > > >> >> > > >> >> > vm_create_jthread from TM. I believe that will resolve
> > > >> >> all our
> > > >> >> > > >> >> > disagreements and the patch will be applied soon.
> > > >> >> > > >> >> >
> > > >> >> > > >> >> >
> > > >> >> > > >> >> > Thanks
> > > >> >> > > >> >> > Evgueni.
> > > >> >> > > >> >> >
> > > >> >> > > >> >> > On 10/4/06, Andrey Chernyshev
> > > >> >> <a....@gmail.com> wrote:
> > > >> >> > > >> >> > > On 10/3/06, Evgueni Brevnov
> > > >> >> <ev...@gmail.com> wrote:
> > > >> >> > > >> >> > > > On 10/3/06, Andrey Chernyshev
> > > >> >> <a....@gmail.com> wrote:
> > > >> >> > > >> >> > > > > On 10/2/06, Evgueni Brevnov
> > > >> >> <ev...@gmail.com> wrote:
> > > >> >> > > >> >> > > > > > Andrey,
> > > >> >> > > >> >> > > > > >
> > > >> >> > > >> >> > > > > > Just to be clear.... I agree with you it is
> > > >> more
> > > >> >> > > >> convenient if
> > > >> >> > > >> >> > > > > > jthread_create takes JNIEnv instead of
> > > >> JavaVM. It
> > > >> >> > > >> reflects that
> > > >> >> > > >> >> > > > > > current thread has been attached already. Do
> > > >> >> you think it
> > > >> >> > > >> >> makes sense
> > > >> >> > > >> >> > > > > > to get rid of JNIEnv and use
> > > >> >> jthread_get_JNI_env in that
> > > >> >> > > >> case?
> > > >> >> > > >> >> > > > >
> > > >> >> > > >> >> > > > > The jthread_* layer is designed like if it were
> > > >> >> a regular JNI
> > > >> >> > > >> >> > > > > application which is meant to be called from the
> > > >> >> Java code,
> > > >> >> > > >> hence
> > > >> >> > > >> >> > > > > every function on that layer receives JNIenv. We
> > > >> >> can probably
> > > >> >> > > >> >> get rid
> > > >> >> > > >> >> > > > > of the JNEnv parameter for jthread_* functions,
> > > >> >> assuming that
> > > >> >> > > >> >> TM can
> > > >> >> > > >> >> > > > > always extract JNIenv for the current thread
> > > >> with
> > > >> >> > > >> >> > > > > jthread_get_JNI_env().
> > > >> >> > > >> >> > > > > My only concern would be the performance - once
> > > >> >> the JNIenv is
> > > >> >> > > >> >> already
> > > >> >> > > >> >> > > > > known for the native part of the kernel classes
> > > >> >> impl, it
> > > >> >> > > >> must be
> > > >> >> > > >> >> > > > > cheaper to pass JNIEnv to TM as an extra
> > > >> >> parameter rather than
> > > >> >> > > >> >> extract
> > > >> >> > > >> >> > > > > it from the TLS again.
> > > >> >> > > >> >> > > > > Other than that, I see no strong advantages in
> > > >> >> keeping JNIEnv
> > > >> >> > > >> >> parameter.
> > > >> >> > > >> >> > > > >
> > > >> >> > > >> >> > > > >
> > > >> >> > > >> >> > > > > > Regarding jthread_attach. I still didn't get
> > > >> >> your point....
> > > >> >> > > >> >> Clarify it
> > > >> >> > > >> >> > > > > > please if you think jhread_attach should be
> > > >> >> modified.
> > > >> >> > > >> >> > > > >
> > > >> >> > > >> >> > > > > Sorry for being not clear: I think for
> > > >> >> jthread_attach, we have
> > > >> >> > > >> >> two options:
> > > >> >> > > >> >> > > > > 1) Make JNIEnv input parameter - it must be new
> > > >> >> JNIEnv that VM
> > > >> >> > > >> >> > > > > pre-allocates for the new Java thread.
> > > >> >> jthread_attach
> > > >> >> > > >> would just
> > > >> >> > > >> >> > > > > associate it with the current thread.
> > > >> >> > > >> >> > > > >
> > > >> >> > > >> >> > > > > 2) Obtain JNIEnv via vm_attach() callback. In
> > > >> >> this case, if
> > > >> >> > > >> >> > > > > vm_attach() callback implementation needs to
> > > >> >> know for which
> > > >> >> > > >> >> JavaVM new
> > > >> >> > > >> >> > > > > JNIenv has to be allocated, then we'll need to
> > > >> >> add JavaVM as
> > > >> >> > > >> >> input
> > > >> >> > > >> >> > > > > parameter for jthread_attach().
> > > >> >> > > >> >> > > > > I think both options should be fine, (1) would
> > > >> >> probably
> > > >> >> > > >> keep TM
> > > >> >> > > >> >> > > > > interface a bit lighter, though (2) may look
> > > >> >> more closer to
> > > >> >> > > >> >> the JNI
> > > >> >> > > >> >> > > > > invocation API idea.
> > > >> >> > > >> >> > > > > So I think adding JavaVM specifically for
> > > >> >> jthread_attach
> > > >> >> > > >> may make
> > > >> >> > > >> >> > > > > sense given the explanation you provided
> > > >> earlier.
> > > >> >> > > >> >> > > > >
> > > >> >> > > >> >> > > > > The concern I would have regarding the proposed
> > > >> >> jthread_attach
> > > >> >> > > >> >> > > > > implementation is a call to vm_create_jthread()
> > > >> >> - this call
> > > >> >> > > >> >> introduces
> > > >> >> > > >> >> > > > > an extra dependency of TM on vmcore that I'd
> > > >> >> prefer to be
> > > >> >> > > >> >> avoided. In
> > > >> >> > > >> >> > > > > the original version, jthread_attach() was
> > > >> >> taking jthread
> > > >> >> > > >> >> argument of
> > > >> >> > > >> >> > > > > the already prepared j.l.Thread.
> > > >> >> > > >> >> > > >
> > > >> >> > > >> >> > > > I understand your concern. Unfortunately I don't
> > > >> >> see what we
> > > >> >> > > >> can do
> > > >> >> > > >> >> > > > here. Let me explain. In the beginning you have an
> > > >> >> unattached
> > > >> >> > > >> >> native
> > > >> >> > > >> >> > > > thread. To be able to call java code (which is
> > > >> >> required for
> > > >> >> > > >> >> > > > constructing j.l.Thread instance) the thread
> > > >> >> should be attached
> > > >> >> > > >> >> first.
> > > >> >> > > >> >> > > > To be specific it should be attached to VM by
> > > >> >> calling vm_attach
> > > >> >> > > >> >> which
> > > >> >> > > >> >> > > > will return a valid JNIEnv It is valid to use JNI
> > > >> >> from that
> > > >> >> > > >> moment.
> > > >> >> > > >> >> > > > Obtained JNIEnv can be used to execute java code
> > > >> >> and create
> > > >> >> > > >> >> j.l.Thread
> > > >> >> > > >> >> > > > instance. Since we do vm_attach in jthread_attach
> > > >> >> we need to do
> > > >> >> > > >> >> > > > vm_create_jthread inside jthread_atach as well.
> > > >> >> > > >> >> > > > Of course it can be an alternative to do vm_attach
> > > >> >> and
> > > >> >> > > >> >> > > > vm_create_jthread outside of TM right before
> > > >> >> jthread_attach.
> > > >> >> > > >> >> Sure it
> > > >> >> > > >> >> > > > will reduce one dependence between VM and TM. But
> > > >> >> it seems like
> > > >> >> > > >> >> > > > artificial action for me just because of
> > > >> >> dependency....
> > > >> >> > > >> >> > >
> > > >> >> > > >> >> > > Why do you think it is artificial? I would rather
> > > >> >> prefer not to
> > > >> >> > > >> throw
> > > >> >> > > >> >> > > vm_attach event from the jthread_attach() call at
> > > >> >> all than to add
> > > >> >> > > >> >> > > extra dependency. The idea of jthread layer is a
> > > >> >> Java face to
> > > >> >> > > >> >> > > hythread, it is meant to know either a little or
> > > >> >> nothing about the
> > > >> >> > > >> >> > > rest of VM. It may be logical to throw vm_attach
> > > >> >> call from the
> > > >> >> > > >> newly
> > > >> >> > > >> >> > > created thread, because there is no other way to let
> > > >> >> know VM
> > > >> >> > > >> the new
> > > >> >> > > >> >> > > thread is created. VM attach is a different case -
> > > >> >> VM already
> > > >> >> > > >> knows
> > > >> >> > > >> >> > > about new Java thread at the time of the
> > > >> >> AttachCurrentThread call.
> > > >> >> > > >> >> > >
> > > >> >> > > >> >> > > >
> > > >> >> > > >> >> > > > > Do you think it makes sense to replace a single
> > > >> >> jthread
> > > >> >> > > >> >> parameter with
> > > >> >> > > >> >> > > > > a variety of stuff (like thread group, name)? It
> > > >> >> seems the
> > > >> >> > > >> only
> > > >> >> > > >> >> > > > > purpose of at these args is to be passed back to
> > > >> >> VM for
> > > >> >> > > >> >> > > > > vm_jthread_create(). I would suggest to change
> > > >> >> this and try
> > > >> >> > > >> doing
> > > >> >> > > >> >> > > > > either of:
> > > >> >> > > >> >> > > > > 1) Make signature of jthread_attach with 3 args,
> > > >> >> JavaVM,
> > > >> >> > > >> >> jthread and the daemon.
> > > >> >> > > >> >> > > > Why do you want to pass daemon to TM but thread's
> > > >> >> name and
> > > >> >> > > >> >> group. Just
> > > >> >> > > >> >> > > > because current TM doesn't need such information?
> > > >> >> What if it is
> > > >> >> > > >> >> > > > required to get thread name later? Say by
> > > >> introducing
> > > >> >> > > >> >> > >
> > > >> >> > > >> >> > > I imagine you need a daemon attribute since the TM
> > > >> >> is still
> > > >> >> > > >> managing
> > > >> >> > > >> >> > > the thread daemonality. TM is not managing thread
> > > >> >> name and group -
> > > >> >> > > >> >> > > they are all kept on the Java level, hence passing
> > > >> >> them may be
> > > >> >> > > >> >> > > excessive.
> > > >> >> > > >> >> > >
> > > >> >> > > >> >> > > > jthread_get_name... What will you do in that case?
> > > >> >> Let me
> > > >> >> > > >> guess you
> > > >> >> > > >> >> > > > will call j.l.Thread.getName. Right. Ok! In that
> > > >> >> case I see no
> > > >> >> > > >> >> > > > problems to call j.l.Thread.isDaemon. Do you
> > > >> >> agree? So it
> > > >> >> > > >> doesn't
> > > >> >> > > >> >> > >
> > > >> >> > > >> >> > > As I suggested earlier, the best way to handle
> > > >> >> daemonality would
> > > >> >> > > >> >> > > probably be in pure Java - in j.l.Thread (or
> > > >> >> > > >> j.l.VMThreadManager) or
> > > >> >> > > >> >> > > whatever. You already lifted it up to the jthread
> > > >> >> level, but
> > > >> >> > > >> what if
> > > >> >> > > >> >> > > we can go a little bit higher...
> > > >> >> > > >> >> > >
> > > >> >> > > >> >> > > > seems to be a good design to pass only part of the
> > > >> >> > > >> information to
> > > >> >> > > >> >> > > > jthread_atach. Lets look at the signature of
> > > >> >> > > >> >> AttachCurrentThread. It
> > > >> >> > > >> >> > > > takes exactly these three parameters (daemon,
> > > >> >> name, group)
> > > >> >> > > >> >> passed as a
> > > >> >> > > >> >> > > > structure. I was thinking about having exactly the
> > > >> >> same
> > > >> >> > > >> >> structure as
> > > >> >> > > >> >> > > > third parameter of jthread_attach but it occured
> > > >> >> to be more
> > > >> >> > > >> >> convinient
> > > >> >> > > >> >> > > > to pass them seperatly. Although I don't see
> > > >> >> strong reasons
> > > >> >> > > >> against
> > > >> >> > > >> >> > > > having a structure a third parameter.
> > > >> >> > > >> >> > >
> > > >> >> > > >> >> > > I see. Acually, I would love to keep the
> > > >> >> jthread_attach func-ty at
> > > >> >> > > >> >> the
> > > >> >> > > >> >> > > minimum level which will be needed to handle the
> > > >> >> only data that TM
> > > >> >> > > >> >> > > should be aware of. We need a formal boundary
> > > >> >> between jthread
> > > >> >> > > >> layer
> > > >> >> > > >> >> > > and vmcore (otherwise jthread won't have a much of
> > > >> >> sense, one may
> > > >> >> > > >> >> > > consider it just as a convenience set of functions
> > > >> >> in vmcore which
> > > >> >> > > >> >> are
> > > >> >> > > >> >> > > doing something with threading).
> > > >> >> > > >> >> > >
> > > >> >> > > >> >> > > >
> > > >> >> > > >> >> > > > > 2) Move the implementation of vm_create_jtrhead
> > > >> >> () to
> > > >> >> > > >> >> > > > > thread_java_basic.c - could it be written in
> > > >> >> pure JNI without
> > > >> >> > > >> >> using
> > > >> >> > > >> >> > > > > internal VM API like class_alloc_new_object()?
> > > >> >> > > >> >> > > >
> > > >> >> > > >> >> > > > Yes, this can be done but it doesn't fix the
> > > >> >> problem. You still
> > > >> >> > > >> >> need
> > > >> >> > > >> >> > > > to know about internal constructor of j.l.Thread
> > > >> >> > > >> >> > >
> > > >> >> > > >> >> > > That's bad. Given what you said, now it seems that
> > > >> >> the most
> > > >> >> > > >> >> preferable
> > > >> >> > > >> >> > > sequence for AttachCurrentThread impl still would be
> > > >> >> like:
> > > >> >> > > >> >> > > JNIEnv = vm_attach();
> > > >> >> > > >> >> > > jthread = create_jthread(JNIenv)
> > > >> >> > > >> >> > > jthread_attach(JNIEnv, jthread) // stores JNIEnv and
> > > >> >> Hythread into
> > > >> >> > > >> >> > > TLS, doesn't call vm_attach any longer.
> > > >> >> > > >> >> > > - this is almost what we had from the beginning...
> > > >> >> > > >> >> > >
> > > >> >> > > >> >> > > Thanks,
> > > >> >> > > >> >> > > Andrey.
> > > >> >> > > >> >> > >
> > > >> >> > > >> >> > > >
> > > >> >> > > >> >> > > >
> > > >> >> > > >> >> > > > Thanks
> > > >> >> > > >> >> > > > Evgueni
> > > >> >> > > >> >> > > > >
> > > >> >> > > >> >> > > > >
> > > >> >> > > >> >> > > > > Thanks,
> > > >> >> > > >> >> > > > > Andrey.
> > > >> >> > > >> >> > > > >
> > > >> >> > > >> >> > > > > >
> > > >> >> > > >> >> > > > > > Thank you
> > > >> >> > > >> >> > > > > > Evgueni
> > > >> >> > > >> >> > > > > >
> > > >> >> > > >> >> > > > > > On 10/2/06, Evgueni Brevnov
> > > >> >> <ev...@gmail.com>
> > > >> >> > > >> wrote:
> > > >> >> > > >> >> > > > > > > On 9/29/06, Andrey Chernyshev
> > > >> >> <a....@gmail.com>
> > > >> >> > > >> >> wrote:
> > > >> >> > > >> >> > > > > > > > On 9/29/06, Evgueni Brevnov
> > > >> >> <ev...@gmail.com>
> > > >> >> > > >> >> wrote:
> > > >> >> > > >> >> > > > > > > > > Artem,
> > > >> >> > > >> >> > > > > > > > >
> > > >> >> > > >> >> > > > > > > > > Thank you for your feedback.... find my
> > > >> >> inlined.....
> > > >> >> > > >> >> > > > > > > > >
> > > >> >> > > >> >> > > > > > > > > On 9/29/06, Artem Aliev
> > > >> >> <ar...@gmail.com> wrote:
> > > >> >> > > >> >> > > > > > > > > > Evgueni,
> > > >> >> > > >> >> > > > > > > > > >
> > > >> >> > > >> >> > > > > > > > > > I got most of your changes, but still
> > > >> >> disagree
> > > >> >> > > >> with all
> > > >> >> > > >> >> > > > > > > > > > hythread/jthread interface changes.
> > > >> >> Could leave
> > > >> >> > > >> >> interface unchanged.
> > > >> >> > > >> >> > > > > > > > > > See following possible solutions, that
> > > >> >> could solve
> > > >> >> > > >> >> the same problems
> > > >> >> > > >> >> > > > > > > > > > without interface changes.
> > > >> >> > > >> >> > > > > > > > > >
> > > >> >> > > >> >> > > > > > > > > >
> > > >> >> > > >> >> > > > > > > > > > 1) daemon attribute is a java
> > > >> >> specific. (Andrey
> > > >> >> > > >> >> mentioned this already).
> > > >> >> > > >> >> > > > > > > > > > Could you please move it back. to
> > > >> >> the jthread
> > > >> >> > > >> >> layer. It is better
> > > >> >> > > >> >> > > > > > > > > > to rename
> > > >> >> > > >> >> > > > > > > > > >
> > > >> >> hythread_wait_for_all_nondaemon_threads() to
> > > >> >> > > >> >> > > > > > > > > >
> > > >> jthread_wait_for_all_nondaemon_threads().
> > > >> >> > > >> >> > > > > > > > > Ok, I see no problems to move "daemon"
> > > >> >> to java layer.
> > > >> >> > > >> >> In that case:
> > > >> >> > > >> >> > > > > > > > > 1) I will move
> > > >> >> > > >> >> hythread_wait_for_all_nondaemon_threads() from
> > > >> >> > > >> >> > > > > > > > > thread_init.c to one which implements
> > > >> >> java layer.
> > > >> >> > > >> >> > > > > > > > > 2) I will move daemon field from
> > > >> >> HyThread structure.
> > > >> >> > > >> >> > > > > > > > >
> > > >> >> > > >> >> > > > > > > > > Agree?
> > > >> >> > > >> >> > > > > > > >
> > > >> >> > > >> >> > > > > > > > Sounds good to me.
> > > >> >> > > >> >> > > > > > >
> > > >> >> > > >> >> > > > > > > OK, will do that.
> > > >> >> > > >> >> > > > > > >
> > > >> >> > > >> >> > > > > > > >
> > > >> >> > > >> >> > > > > > > >
> > > >> >> > > >> >> > > > > > > > >
> > > >> >> > > >> >> > > > > > > > > >
> > > >> >> > > >> >> > > > > > > > > > 2) JavaVM could be retrieved from
> > > >> >> JNIEnv by
> > > >> >> > > >> >> jni_get_java_vm(). So
> > > >> >> > > >> >> > > > > > > > > > let the jthread_create() and others to
> > > >> >> use JNIEnv
> > > >> >> > > >> >> (that is passed from
> > > >> >> > > >> >> > > > > > > > > > java native method).
> > > >> >> > > >> >> > > > > > > > > > The vm_attach could get old JNI env
> > > >> >> and create new
> > > >> >> > > >> >> one for the new thread.
> > > >> >> > > >> >> > > > > > > > > > The first JNIEnv is created in
> > > >> >> CreateVM call and
> > > >> >> > > >> >> could be passed to
> > > >> >> > > >> >> > > > > > > > > > the first thread at startup.
> > > >> >> > > >> >> > > > > > > > > No, no, no. I completely disagree with
> > > >> >> that!!! Why do
> > > >> >> > > >> >> you like JNIEnv
> > > >> >> > > >> >> > > > > > > > > but JavaVM. Why do you think that
> > > >> >> passing JavaVM
> > > >> >> > > >> >> instead of JNIEnv
> > > >> >> > > >> >> > > > > > > > > makes TM less modular? I don't see any
> > > >> >> difference
> > > >> >> > > >> >> here.... It seems
> > > >> >> > > >> >> > > > > > > > > for me like a big big hack to grab
> > > >> >> JNIEnv from another
> > > >> >> > > >> >> thread and pass
> > > >> >> > > >> >> > > > > > > > > it to jthread_attach to perform
> > > >> >> operations in the
> > > >> >> > > >> >> current thread.
> > > >> >> > > >> >> > > > > > > >
> > > >> >> > > >> >> > > > > > > > TM needs to know JNIEnv, mainly for
> > > >> >> managing the
> > > >> >> > > >> >> references to
> > > >> >> > > >> >> > > > > > > > objects, throwing exceptions and calling
> > > >> >> run() method of
> > > >> >> > > >> >> a new thread.
> > > >> >> > > >> >> > > > > > > > JNI spec proposes that JNIEnv is valid
> > > >> >> within the given
> > > >> >> > > >> >> thread, this
> > > >> >> > > >> >> > > > > > > > is why TM holds the JNIEnv pointer at the
> > > >> >> moment. This
> > > >> >> > > >> >> is why TM likes
> > > >> >> > > >> >> > > > > > > > the JNIEnv.
> > > >> >> > > >> >> > > > > > > >
> > > >> >> > > >> >> > > > > > > > Having the JNIEnv, one is able to get
> > > >> >> JavaVM but not
> > > >> >> > > >> >> vise versa. This
> > > >> >> > > >> >> > > > > > > > is why TM doesn't like the JavaVM :)
> > > >> >> > > >> >> > > > > > > I see your point. Only one note this is true
> > > >> >> for already
> > > >> >> > > >> >> attached threads...
> > > >> >> > > >> >> > > > > > >
> > > >> >> > > >> >> > > > > > > >
> > > >> >> > > >> >> > > > > > > > I agree with you that there is a design
> > > >> >> flaw that the
> > > >> >> > > >> >> JNIEnv is copied
> > > >> >> > > >> >> > > > > > > > from the parent thread to a child thread
> > > >> >> during thread
> > > >> >> > > >> >> creation. I
> > > >> >> > > >> >> > > > > > > > think it could be resolved via vm_attach()
> > > >> >> hook - with
> > > >> >> > > >> >> this event, VM
> > > >> >> > > >> >> > > > > > > > might tell the TM what the JNIEnv pointer
> > > >> >> for new thread
> > > >> >> > > >> >> should be. I
> > > >> >> > > >> >> > > > > > > > think you did that by extending the
> > > >> >> vm_attach() call
> > > >> >> > > >> >> with the JNIEnv**
> > > >> >> > > >> >> > > > > > > > argument.
> > > >> >> > > >> >> > > > > > > >
> > > >> >> > > >> >> > > > > > > > What is not completely clear is, why do
> > > >> >> you have to pass
> > > >> >> > > >> >> the JavaVM
> > > >> >> > > >> >> > > > > > > > forth and back, once from VM to TM, and
> > > >> >> then back from
> > > >> >> > > >> >> TM to VM again?
> > > >> >> > > >> >> > > > > > > >
> > > >> >> > > >> >> > > > > > > > If you need to know in jthread_attach,
> > > >> >> which particular
> > > >> >> > > >> >> VM vm_attach()
> > > >> >> > > >> >> > > > > > > > event is coming from, you could have
> > > >> >> vm_attach like
> > > >> >> > > >> >> > > > > > > > vm_attach(JNIEnv* currentThreadEnv,
> > > >> JNIEnv**
> > > >> >> > > >> >> newThreadEnv).
> > > >> >> > > >> >> > > > > > > I'm a little bit confused.....Current thread
> > > >> >> hasn't been
> > > >> >> > > >> >> attached yet.
> > > >> >> > > >> >> > > > > > > So there is no JNIEnv for it yet. How it can
> > > >> >> be passed as
> > > >> >> > > >> >> the first
> > > >> >> > > >> >> > > > > > > parameter to vm_attach()?
> > > >> >> > > >> >> > > > > > >
> > > >> >> > > >> >> > > > > > > > Then you will be always able to get the
> > > >> >> JavaVM from the
> > > >> >> > > >> >> JNIEnv.
> > > >> >> > > >> >> > > > > > > > The only difference is that you are
> > > >> >> currently doing
> > > >> >> > > >> >> JNIEnv->JavaVM
> > > >> >> > > >> >> > > > > > > > conversion in the VMThreadManager, but why
> > > >> >> can't you
> > > >> >> > > >> >> just do this in
> > > >> >> > > >> >> > > > > > > > vm_attach() without changing the interface
> > > >> >> of the TM?
> > > >> >> > > >> >> > > > > > > > So far JavaVM really looks like an extra
> > > >> >> knowledge that
> > > >> >> > > >> >> TM doesn't
> > > >> >> > > >> >> > > > > > > > have to be aware of.
> > > >> >> > > >> >> > > > > > > >
> > > >> >> > > >> >> > > > > > > > > Moreover there is no JNIEnv when main
> > > >> >> thread attaches
> > > >> >> > > >> >> to VM. So we
> > > >> >> > > >> >> > > > > > > > > should either keep it as is or change
> > > >> >> original design
> > > >> >> > > >> >> of TM and attach
> > > >> >> > > >> >> > > > > > > > > thread to VM before attaching it to TM.
> > > >> >> In that case
> > > >> >> > > >> >> we will have
> > > >> >> > > >> >> > > > > > > > > valid JNIEnv which can be passed to
> > > >> >> jthread_atatch. We
> > > >> >> > > >> >> need to think
> > > >> >> > > >> >> > > > > > > > > over it twice before changing
> > > >> something....
> > > >> >> > > >> >> > > > > > > >
> > > >> >> > > >> >> > > > > > > > Right. For jthread_attach, JNIenv needs to
> > > >> >> be changed
> > > >> >> > > >> >> from being input
> > > >> >> > > >> >> > > > > > > > parameter to being the output parameter.
> > > >> >> The way how
> > > >> >> > > >> >> JNIenv is
> > > >> >> > > >> >> > > > > > > > obtained by TM should be vm_attach()
> > > >> event.
> > > >> >> > > >> >> > > > > > > OK, JNIEnv is output parameter. And it
> > > >> >> obtained by
> > > >> >> > > >> >> vm_attach(). This
> > > >> >> > > >> >> > > > > > > is exactly like I do in the patch. What I
> > > >> >> don't understand
> > > >> >> > > >> >> is how
> > > >> >> > > >> >> > > > > > > jthread_attach knows to which VM the thread
> > > >> >> should be
> > > >> >> > > >> >> attached? Do you
> > > >> >> > > >> >> > > > > > > suggest calling vm_attach first to create
> > > >> >> JNIEnv it pass
> > > >> >> > > >> >> it to
> > > >> >> > > >> >> > > > > > > jthread_attach?
> > > >> >> > > >> >> > > > > > >
> > > >> >> > > >> >> > > > > > > >
> > > >> >> > > >> >> > > > > > > > >
> > > >> >> > > >> >> > > > > > > > >
> > > >> >> > > >> >> > > > > > > > >
> > > >> >> > > >> >> > > > > > > > > >
> > > >> >> > > >> >> > > > > > > > > >
> > > >> >> > > >> >> > > > > > > > > > 4) Original classlib hythread do
> > > >> not use
> > > >> >> > > >> >> hythread_library_t in arguments,
> > > >> >> > > >> >> > > > > > > > > > It uses following code:
> > > >> >> > > >> >> > > > > > > > > >
> > > >> >> > > >> >> > > > > > > > > > hythread_library_t lib = GLOBAL_DATA
> > > >> >> > > >> >> (default_library);
> > > >> >> > > >> >> > > > > > > > > > or
> > > >> >> > > >> >> > > > > > > > > > hythread_library_t library = thread-
> > > >> >> >library;
> > > >> >> > > >> >> > > > > > > > > >
> > > >> >> > > >> >> > > > > > > > > > So could you please use the same
> > > >> >> mechanism and
> > > >> >> > > >> >> remove hythread_*_ex >functions.
> > > >> >> > > >> >> > > > > > > > > Let's see if classlib's hythread needs
> > > >> >> changing first.
> > > >> >> > > >> >> It seems for me
> > > >> >> > > >> >> > > > > > > > > such code prevents us from having
> > > >> multi VM.
> > > >> >> > > >> >> > > > > > > > >
> > > >> >> > > >> >> > > > > > > > > >
> > > >> >> > > >> >> > > > > > > > > > 5. You introduce more then one jni
> > > >> >> env, but still
> > > >> >> > > >> >> use global variable for it.
> > > >> >> > > >> >> > > > > > > > > > So all changes like following:
> > > >> >> > > >> >> > > > > > > > > > - JNIEnv *jenv = (JNIEnv*)
> > > >> >> jni_native_intf;
> > > >> >> > > >> >> > > > > > > > > > + JNIEnv *jenv = jni_native_intf;
> > > >> >> > > >> >> > > > > > > > > >
> > > >> >> > > >> >> > > > > > > > > > should be like:
> > > >> >> > > >> >> > > > > > > > > > - JNIEnv *jenv = (JNIEnv*)
> > > >> >> jni_native_intf;
> > > >> >> > > >> >> > > > > > > > > > + JNIEnv *jenv = get_jni_env
> > > >> >> (jthread_self());
> > > >> >> > > >> >> > > > > > > > >
> > > >> >> > > >> >> > > > > > > > > Ok, I see. I agree that global
> > > >> >> jni_native_intf should
> > > >> >> > > >> >> not be used.
> > > >> >> > > >> >> > > > > > > > > There was simple reason why I altered
> > > >> >> such lines.
> > > >> >> > > >> >> Because I changed
> > > >> >> > > >> >> > > > > > > > > the type of jni_native_intf and no
> > > >> >> casting operator
> > > >> >> > > >> >> is needed now. To
> > > >> >> > > >> >> > > > > > > > > be honest I think get_jni_env
> > > >> >> (jthread_self()) can be
> > > >> >> > > >> >> good as temporary
> > > >> >> > > >> >> > > > > > > > > solution only. Lets wait for design of
> > > >> >> multi VM and
> > > >> >> > > >> >> fix it according
> > > >> >> > > >> >> > > > > > > > > to it.
> > > >> >> > > >> >> > > > > > > >
> > > >> >> > > >> >> > > > > > > > While we are in JNI code, we always have
> > > >> >> the JNIenv (at
> > > >> >> > > >> >> least
> > > >> >> > > >> >> > > > > > > > initially it comes from Java code). If we
> > > >> >> consider VM
> > > >> >> > > >> >> code as if it
> > > >> >> > > >> >> > > > > > > > was a JNI application, then it seems like
> > > >> >> we should be
> > > >> >> > > >> >> just passing
> > > >> >> > > >> >> > > > > > > > JNIEnv as a parameter to all functions in
> > > >> >> VM. Or, we can
> > > >> >> > > >> >> be taking it
> > > >> >> > > >> >> > > > > > > > from TLS (via jthread_self()), depending
> > > >> >> on which way is
> > > >> >> > > >> >> faster...
> > > >> >> > > >> >> > > > > > > Agree.
> > > >> >> > > >> >> > > > > > >
> > > >> >> > > >> >> > > > > > > >
> > > >> >> > > >> >> > > > > > > > >
> > > >> >> > > >> >> > > > > > > > > >
> > > >> >> > > >> >> > > > > > > > > > 6). And small remarks:
> > > >> >> > > >> >> > > > > > > > > > +jint vm_init1(JavaVM_Internal *
> > > >> java_vm,
> > > >> >> > > >> >> JavaVMInitArgs * vm_arguments);
> > > >> >> > > >> >> > > > > > > > > > +jint vm_init2(JNIEnv_Internal *
> > > >> >> jni_env);
> > > >> >> > > >> >> > > > > > > > > > Could you make names more meaningful,
> > > >> >> then 1,2,3...?
> > > >> >> > > >> >> > > > > > > > > Ok, will do that.
> > > >> >> > > >> >> > > > > > > > >
> > > >> >> > > >> >> > > > > > > > > >
> > > >> >> > > >> >> > > > > > > > > > class VM_thread {
> > > >> >> > > >> >> > > > > > > > > > ...
> > > >> >> > > >> >> > > > > > > > > > + JNIEnv_Internal * jni_env;
> > > >> >> > > >> >> > > > > > > > > > The jthread already has the jni_env
> > > >> >> pointer, you do
> > > >> >> > > >> >> not need to
> > > >> >> > > >> >> > > > > > > > > > duplicate it here.
> > > >> >> > > >> >> > > > > > > > > > forexample by using
> > > >> >> > > >> >> jthread_get_JNI_env(jthread_self());
> > > >> >> > > >> >> > > > > > > > >
> > > >> >> > > >> >> > > > > > > > > Yes I know. I don't see any problems
> > > >> >> here. Some times
> > > >> >> > > >> >> it is much more
> > > >> >> > > >> >> > > > > > > > > convenient to get JNIEnv from VM_thread
> > > >> >> structure (and
> > > >> >> > > >> >> faster) instead
> > > >> >> > > >> >> > > > > > > > > of doing jthread_get_JNI_env
> > > >> (jthread_self
> > > >> >> ()). So I
> > > >> >> > > >> >> need strong
> > > >> >> > > >> >> > > > > > > > > arguments for removing it. Again it
> > > >> >> seems that should
> > > >> >> > > >> >> be addressed in
> > > >> >> > > >> >> > > > > > > > > design of multi VM. So lets forget about
> > > >> >> it for a
> > > >> >> > > >> >> while...
> > > >> >> > > >> >> > > > > > > >
> > > >> >> > > >> >> > > > > > > > I think that the data duplication would
> > > >> >> always serve as
> > > >> >> > > >> >> a potential
> > > >> >> > > >> >> > > > > > > > source of errors - while updating one copy
> > > >> >> of object,
> > > >> >> > > >> >> you may forget
> > > >> >> > > >> >> > > > > > > > to update the other, often resulting into
> > > >> >> a strange
> > > >> >> > > >> >> behavior of the
> > > >> >> > > >> >> > > > > > > > whole application. Let's see what are the
> > > >> >> specific
> > > >> >> > > >> >> performance
> > > >> >> > > >> >> > > > > > > > concerns that have to be addressed. To get
> > > >> >> VM_thread
> > > >> >> > > >> >> structure, you
> > > >> >> > > >> >> > > > > > > > would eventually go to the TLS, just like
> > > >> >> > > >> >> > > > > > > > jthread_get_JNI_env(jthread_self()
> > > >> would do.
> > > >> >> > > >> >> > > > > > > If there is already VM_thread structure for
> > > >> >> some reasons
> > > >> >> > > >> >> then there
> > > >> >> > > >> >> > > > > > > will be no extra access to TLS. It is
> > > >> >> definitely much
> > > >> >> > > >> more in
> > > >> >> > > >> >> > > > > > > jthread_get_JNI_env(jthread_self() than just
> > > >> >> one TLS
> > > >> >> > > >> >> access and one
> > > >> >> > > >> >> > > > > > > dereferncing. I don't think it is a really
> > > >> >> big problem
> > > >> >> > > >> >> now. Do you
> > > >> >> > > >> >> > > > > > > agree to look at this later. I guess
> > > >> multi VM
> > > >> >> > > >> >> implementation will
> > > >> >> > > >> >> > > > > > > alter it in any case.
> > > >> >> > > >> >> > > > > > >
> > > >> >> > > >> >> > > > > > > Thanks
> > > >> >> > > >> >> > > > > > > Evgueni
> > > >> >> > > >> >> > > > > > >
> > > >> >> > > >> >> > > > > > > >
> > > >> >> > > >> >> > > > > > > > Thanks,
> > > >> >> > > >> >> > > > > > > > Andrey.
> > > >> >> > > >> >> > > > > > > >
> > > >> >> > > >> >> > > > > > > > >
> > > >> >> > > >> >> > > > > > > > > Evgueni
> > > >> >> > > >> >> > > > > > > > > >
> > > >> >> > > >> >> > > > > > > > > > Thanks
> > > >> >> > > >> >> > > > > > > > > > Artem
> > > >> >> > > >> >> > > > > > > > > >
> > > >> >> > > >> >> > > > > > > > > > On 9/28/06, Evgueni Brevnov
> > > >> >> > > >> >> <ev...@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.
> > > >> >> > > >> >> > > > > > > > > > >
> > > >> >> > > >> >> > > > > > > > > > > Thanks
> > > >> >> > > >> >> > > > > > > > > > > Evgueni
> > > >> >> > > >> >> > > > > > > > > > >
> > > >> >> > > >> >> > > > > > > > > > > On 9/28/06, Geir Magnusson Jr.
> > > >> >> <ge...@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
> > > >> >> > > >> >> <we...@gmail.com> wrote:
> > > >> >> > > >> >> > > > > > > > > > > > >> On 9/26/06, Evgueni Brevnov
> > > >> >> > > >> >> <ev...@gmail.com> wrote:
> > > >> >> > > >> >> > > > > > > > > > > > >> >
> > > >> >> > > >> >> > > > > > > > > > > > >> > On 9/27/06, Andrey Chernyshev
> > > >> >> > > >> >> <a....@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
> > > >> >> > > >> >> > > > > > > > > > >
> > > >> >> > > >> >> > > > > > > > > > >
> > > >> >> > > >> >> > > > > > > > > >
> > > >> >> > > >> >> > > > > > > > > >
> > > >> >> > > >> >>
> > > >> >>
> > > >> ---------------------------------------------------------------------
> > > >> >> > > >> >> > > > > > > > > > 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
> > > >> >> > > >> >> > > > > > > > >
> > > >> >> > > >> >> > > > > > > > >
> > > >> >> > > >> >> > > > > > > >
> > > >> >> > > >> >> > > > > > > >
> > > >> >> > > >> >> > > > > > > > --
> > > >> >> > > >> >> > > > > > > > Andrey Chernyshev
> > > >> >> > > >> >> > > > > > > > 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
> > > >> >> > > >> >> > > > > >
> > > >> >> > > >> >> > > > > >
> > > >> >> > > >> >> > > > >
> > > >> >> > > >> >> > > > >
> > > >> >> > > >> >> > > > > --
> > > >> >> > > >> >> > > > > Andrey Chernyshev
> > > >> >> > > >> >> > > > > 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
> > > >> >> > > >> >> > > >
> > > >> >> > > >> >> > > >
> > > >> >> > > >> >> > >
> > > >> >> > > >> >> > >
> > > >> >> > > >> >> > > --
> > > >> >> > > >> >> > > Andrey Chernyshev
> > > >> >> > > >> >> > > 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
> > > >> >> > > >>
> > > >> >> > > >>
> > > >> >> > > >
> > > >> >> > > >
> > > >> >>
> > > >> ---------------------------------------------------------------------
> > > >> >> > > > 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
> > > >> >
> > > >>
> > > >>
> > > >> ---------------------------------------------------------------------
> > > >> 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
> > >
> > >
> >
>
---------------------------------------------------------------------
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
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
Posted by Evgueni Brevnov <ev...@gmail.com>.
Does this mean you will commit the patch soon? :-)
On 10/9/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>
>
> Evgueni Brevnov wrote:
> > Geir, Salikh,
> >
> > cunit tests are very unstable...... that's why we have different
> > results on different platforms. It all tests problems. I already fixed
> > several places but it seems there is much more left. I believe we need
> > to revise them all. The main problem is that sleep(somthing) is used
> > to synchronize different threads. Sometimes there is no synchraniztion
> > at all. I propouse for switching it off until they get stable.
> > Can we do it?
>
> No. They all pass for me now, and I think that they are important as
> they are better than nothing.
>
> I suspected that these were just timing issues - we should just hunker
> down and get them fixed ASAP. We're making progress
>
> geir
>
> >
> > Evgueni
> >
> > On 10/9/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> >> Could you insert sleep_a_click(); just before line 59 right after
> >> hysem_create(&start, 0, 1):
> >>
> >> Does it help?
> >>
> >> On 10/9/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> >> > [echo] ## Executing C unit test: test_ti_instrum
> >> > [exec] Result: 1
> >> > [echo] INFO: TEST test_jthread_get_all_threads start
> >> > [echo] ERROR: Assertion '(thread_count)==(i +
> >> > initial_thread_count)' failed at /home/geir/dev/apache/harmony/
> >> > enhanced/trunk/working_vm/vm/tes
> >> > ts/unit/thread/test_ti_instrum.c:94
> >> > [echo] Init1: initial_thread_count=1, initial_all_threads_count=1
> >> > [echo] Init3: initial_thread_count=1, initial_all_threads_count=1
> >> > [echo] Init3: thread_count=3, all_threads_count=3
> >> > [echo] INFO: TEST test_jthread_get_all_threads: FAILED
> >> > [echo] INFO: TEST test_jthread_get_thread_count start
> >> > [echo] Init1: initial_thread_count=3, initial_all_threads_count=3
> >> > [echo] INFO: TEST test_jthread_get_thread_count: PASSED
> >> > [echo] INFO: TEST test_jthread_get_blocked_count start
> >> > [echo] INFO: TEST test_jthread_get_blocked_count: PASSED
> >> > [echo] ## TEST FAILED
> >> >
> >> >
> >> > On Oct 9, 2006, at 12:35 AM, Evgueni Brevnov wrote:
> >> >
> >> > > I put debug printing into test_ti_instrum.c and attached it to JIRA.
> >> > > Could you run it on your machine and send me console output.
> >> > >
> >> > > Evgueni
> >> > >
> >> > > On 10/9/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> >> > >> I keep getting a failure when running the tests -
> >> > >>
> >> > >> test_jthread_get_all-threads failling the assertion at
> >> > >> test_ti_instrum.c:80
> >> > >>
> >> > >> geir
> >> > >>
> >> > >> On Oct 8, 2006, at 7:19 AM, Evgueni Brevnov wrote:
> >> > >>
> >> > >> > While running cunit on Linux it turned out one test case fails
> >> some
> >> > >> > time. The fix is in tests.final.2.patch.
> >> > >> >
> >> > >> > So the last versions to be committed:
> >> > >> > invocation_api.final.patch
> >> > >> > build.final.2.patch
> >> > >> > tests.final.2.patch
> >> > >> >
> >> > >> > Evgueni
> >> > >> >
> >> > >> >
> >> > >> > On 10/8/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> >> > >> >> I mahaged to resolve the problem on Linux.... will update
> >> > >> >> build.final.patch with build.final.2.patch in a while
> >> > >> >>
> >> > >> >> On 10/8/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> >> > >> >> > Hi,
> >> > >> >> >
> >> > >> >> > Oh! Ooh! I did that..... I passed cunit, somke, kernel tests on
> >> > >> >> > Windows and smoke, kernel tests on Linux. Unfortunately I
> >> > >> failed to
> >> > >> >> > link cunit tests on Linux so far. So I disabled cunit on Linux
> >> > >> >> until
> >> > >> >> > the problem is solved. I believe it is acceptable as short term
> >> > >> >> > solution. I found several problems in cunit tests. I will come
> >> > >> >> up with
> >> > >> >> > my findings later (not today).
> >> > >> >> >
> >> > >> >> > Use latest patches from HARMONY-1582. They are marked as final.
> >> > >> >> There
> >> > >> >> > are three patches. One for build module, one for cunit tests
> >> and
> >> > >> >> one
> >> > >> >> > for VM itself.
> >> > >> >> >
> >> > >> >> > Thanks
> >> > >> >> > Evgueni
> >> > >> >> >
> >> > >> >> >
> >> > >> >> > On 10/6/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> >> > >> >> > > Nooooooo! LOL
> >> > >> >> > >
> >> > >> >> > > I'm here waiting - This will unblock a whole bunch of
> >> > >> things :)
> >> > >> >> > >
> >> > >> >> > > Thanks for the effort
> >> > >> >> > >
> >> > >> >> > > Evgueni Brevnov wrote:
> >> > >> >> > > > Geir,
> >> > >> >> > > >
> >> > >> >> > > > That's terrible. We have power outage....servers are
> >> down. I
> >> > >> >> can't
> >> > >> >> > > > send the patches now.... will do it tomorrow
> >> > >> >> > > >
> >> > >> >> > > > Evgueni
> >> > >> >> > > > On 10/5/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> >> > >> >> > > >> woo hoo! here we go...
> >> > >> >> > > >>
> >> > >> >> > > >>
> >> > >> >> > > >> Andrey Chernyshev wrote:
> >> > >> >> > > >> > Hi Evgueni,
> >> > >> >> > > >> >
> >> > >> >> > > >> > On 10/4/06, Evgueni Brevnov <ev...@gmail.com>
> >> > >> >> wrote:
> >> > >> >> > > >> >> Hi All,
> >> > >> >> > > >> >>
> >> > >> >> > > >> >> I have attached updated patch to the JIRA. It should
> >> > >> >> resolve remain
> >> > >> >> > > >> >> concerns. Andrey, could you give a green light now?
> >> > >> >> > > >> >
> >> > >> >> > > >> > Thanks for updating the patch! I agree it it can be
> >> > >> >> committed, at
> >> > >> >> > > >> > least signatures look good. 5 revisions seem like more
> >> > >> >> than enough :).
> >> > >> >> > > >> > Anyways, I think the remaining issues can be resolved
> >> > >> >> with additional
> >> > >> >> > > >> > patches. Thanks again for the good work and your
> >> > >> patience.
> >> > >> >> > > >> >
> >> > >> >> > > >> > Thanks,
> >> > >> >> > > >> > Andrey.
> >> > >> >> > > >> >
> >> > >> >> > > >> >>
> >> > >> >> > > >> >> Thanks
> >> > >> >> > > >> >> Evgueni
> >> > >> >> > > >> >>
> >> > >> >> > > >> >> On 10/4/06, Evgueni Brevnov <ev...@gmail.com>
> >> > >> >> wrote:
> >> > >> >> > > >> >> > Andrey,
> >> > >> >> > > >> >> >
> >> > >> >> > > >> >> > I see your points. I think both approaches have
> >> > >> >> advantages and
> >> > >> >> > > >> >> > disadvantages. I think it is quite hard to say which
> >> > >> >> approach is
> >> > >> >> > > >> >> > better until we play with one VM only. I still feel
> >> > >> >> like introducing
> >> > >> >> > > >> >> > one more dependence is better than spreading code
> >> > >> >> which deals with
> >> > >> >> > > >> >> > attachment among VM and TM. We really get stuck. OK,
> >> > >> >> just because I
> >> > >> >> > > >> >> > want to move forward I will do required changes to
> >> > >> remove
> >> > >> >> > > >> >> > vm_create_jthread from TM. I believe that will
> >> resolve
> >> > >> >> all our
> >> > >> >> > > >> >> > disagreements and the patch will be applied soon.
> >> > >> >> > > >> >> >
> >> > >> >> > > >> >> >
> >> > >> >> > > >> >> > Thanks
> >> > >> >> > > >> >> > Evgueni.
> >> > >> >> > > >> >> >
> >> > >> >> > > >> >> > On 10/4/06, Andrey Chernyshev
> >> > >> >> <a....@gmail.com> wrote:
> >> > >> >> > > >> >> > > On 10/3/06, Evgueni Brevnov
> >> > >> >> <ev...@gmail.com> wrote:
> >> > >> >> > > >> >> > > > On 10/3/06, Andrey Chernyshev
> >> > >> >> <a....@gmail.com> wrote:
> >> > >> >> > > >> >> > > > > On 10/2/06, Evgueni Brevnov
> >> > >> >> <ev...@gmail.com> wrote:
> >> > >> >> > > >> >> > > > > > Andrey,
> >> > >> >> > > >> >> > > > > >
> >> > >> >> > > >> >> > > > > > Just to be clear.... I agree with you it is
> >> > >> more
> >> > >> >> > > >> convenient if
> >> > >> >> > > >> >> > > > > > jthread_create takes JNIEnv instead of
> >> > >> JavaVM. It
> >> > >> >> > > >> reflects that
> >> > >> >> > > >> >> > > > > > current thread has been attached already. Do
> >> > >> >> you think it
> >> > >> >> > > >> >> makes sense
> >> > >> >> > > >> >> > > > > > to get rid of JNIEnv and use
> >> > >> >> jthread_get_JNI_env in that
> >> > >> >> > > >> case?
> >> > >> >> > > >> >> > > > >
> >> > >> >> > > >> >> > > > > The jthread_* layer is designed like if it were
> >> > >> >> a regular JNI
> >> > >> >> > > >> >> > > > > application which is meant to be called from
> >> the
> >> > >> >> Java code,
> >> > >> >> > > >> hence
> >> > >> >> > > >> >> > > > > every function on that layer receives
> >> JNIenv. We
> >> > >> >> can probably
> >> > >> >> > > >> >> get rid
> >> > >> >> > > >> >> > > > > of the JNEnv parameter for jthread_* functions,
> >> > >> >> assuming that
> >> > >> >> > > >> >> TM can
> >> > >> >> > > >> >> > > > > always extract JNIenv for the current thread
> >> > >> with
> >> > >> >> > > >> >> > > > > jthread_get_JNI_env().
> >> > >> >> > > >> >> > > > > My only concern would be the performance -
> >> once
> >> > >> >> the JNIenv is
> >> > >> >> > > >> >> already
> >> > >> >> > > >> >> > > > > known for the native part of the kernel classes
> >> > >> >> impl, it
> >> > >> >> > > >> must be
> >> > >> >> > > >> >> > > > > cheaper to pass JNIEnv to TM as an extra
> >> > >> >> parameter rather than
> >> > >> >> > > >> >> extract
> >> > >> >> > > >> >> > > > > it from the TLS again.
> >> > >> >> > > >> >> > > > > Other than that, I see no strong advantages in
> >> > >> >> keeping JNIEnv
> >> > >> >> > > >> >> parameter.
> >> > >> >> > > >> >> > > > >
> >> > >> >> > > >> >> > > > >
> >> > >> >> > > >> >> > > > > > Regarding jthread_attach. I still didn't get
> >> > >> >> your point....
> >> > >> >> > > >> >> Clarify it
> >> > >> >> > > >> >> > > > > > please if you think jhread_attach should be
> >> > >> >> modified.
> >> > >> >> > > >> >> > > > >
> >> > >> >> > > >> >> > > > > Sorry for being not clear: I think for
> >> > >> >> jthread_attach, we have
> >> > >> >> > > >> >> two options:
> >> > >> >> > > >> >> > > > > 1) Make JNIEnv input parameter - it must be new
> >> > >> >> JNIEnv that VM
> >> > >> >> > > >> >> > > > > pre-allocates for the new Java thread.
> >> > >> >> jthread_attach
> >> > >> >> > > >> would just
> >> > >> >> > > >> >> > > > > associate it with the current thread.
> >> > >> >> > > >> >> > > > >
> >> > >> >> > > >> >> > > > > 2) Obtain JNIEnv via vm_attach() callback. In
> >> > >> >> this case, if
> >> > >> >> > > >> >> > > > > vm_attach() callback implementation needs to
> >> > >> >> know for which
> >> > >> >> > > >> >> JavaVM new
> >> > >> >> > > >> >> > > > > JNIenv has to be allocated, then we'll need to
> >> > >> >> add JavaVM as
> >> > >> >> > > >> >> input
> >> > >> >> > > >> >> > > > > parameter for jthread_attach().
> >> > >> >> > > >> >> > > > > I think both options should be fine, (1) would
> >> > >> >> probably
> >> > >> >> > > >> keep TM
> >> > >> >> > > >> >> > > > > interface a bit lighter, though (2) may look
> >> > >> >> more closer to
> >> > >> >> > > >> >> the JNI
> >> > >> >> > > >> >> > > > > invocation API idea.
> >> > >> >> > > >> >> > > > > So I think adding JavaVM specifically for
> >> > >> >> jthread_attach
> >> > >> >> > > >> may make
> >> > >> >> > > >> >> > > > > sense given the explanation you provided
> >> > >> earlier.
> >> > >> >> > > >> >> > > > >
> >> > >> >> > > >> >> > > > > The concern I would have regarding the proposed
> >> > >> >> jthread_attach
> >> > >> >> > > >> >> > > > > implementation is a call to vm_create_jthread()
> >> > >> >> - this call
> >> > >> >> > > >> >> introduces
> >> > >> >> > > >> >> > > > > an extra dependency of TM on vmcore that I'd
> >> > >> >> prefer to be
> >> > >> >> > > >> >> avoided. In
> >> > >> >> > > >> >> > > > > the original version, jthread_attach() was
> >> > >> >> taking jthread
> >> > >> >> > > >> >> argument of
> >> > >> >> > > >> >> > > > > the already prepared j.l.Thread.
> >> > >> >> > > >> >> > > >
> >> > >> >> > > >> >> > > > I understand your concern. Unfortunately I don't
> >> > >> >> see what we
> >> > >> >> > > >> can do
> >> > >> >> > > >> >> > > > here. Let me explain. In the beginning you
> >> have an
> >> > >> >> unattached
> >> > >> >> > > >> >> native
> >> > >> >> > > >> >> > > > thread. To be able to call java code (which is
> >> > >> >> required for
> >> > >> >> > > >> >> > > > constructing j.l.Thread instance) the thread
> >> > >> >> should be attached
> >> > >> >> > > >> >> first.
> >> > >> >> > > >> >> > > > To be specific it should be attached to VM by
> >> > >> >> calling vm_attach
> >> > >> >> > > >> >> which
> >> > >> >> > > >> >> > > > will return a valid JNIEnv It is valid to use JNI
> >> > >> >> from that
> >> > >> >> > > >> moment.
> >> > >> >> > > >> >> > > > Obtained JNIEnv can be used to execute java code
> >> > >> >> and create
> >> > >> >> > > >> >> j.l.Thread
> >> > >> >> > > >> >> > > > instance. Since we do vm_attach in jthread_attach
> >> > >> >> we need to do
> >> > >> >> > > >> >> > > > vm_create_jthread inside jthread_atach as well.
> >> > >> >> > > >> >> > > > Of course it can be an alternative to do
> >> vm_attach
> >> > >> >> and
> >> > >> >> > > >> >> > > > vm_create_jthread outside of TM right before
> >> > >> >> jthread_attach.
> >> > >> >> > > >> >> Sure it
> >> > >> >> > > >> >> > > > will reduce one dependence between VM and TM. But
> >> > >> >> it seems like
> >> > >> >> > > >> >> > > > artificial action for me just because of
> >> > >> >> dependency....
> >> > >> >> > > >> >> > >
> >> > >> >> > > >> >> > > Why do you think it is artificial? I would rather
> >> > >> >> prefer not to
> >> > >> >> > > >> throw
> >> > >> >> > > >> >> > > vm_attach event from the jthread_attach() call at
> >> > >> >> all than to add
> >> > >> >> > > >> >> > > extra dependency. The idea of jthread layer is a
> >> > >> >> Java face to
> >> > >> >> > > >> >> > > hythread, it is meant to know either a little or
> >> > >> >> nothing about the
> >> > >> >> > > >> >> > > rest of VM. It may be logical to throw vm_attach
> >> > >> >> call from the
> >> > >> >> > > >> newly
> >> > >> >> > > >> >> > > created thread, because there is no other way to
> >> let
> >> > >> >> know VM
> >> > >> >> > > >> the new
> >> > >> >> > > >> >> > > thread is created. VM attach is a different case -
> >> > >> >> VM already
> >> > >> >> > > >> knows
> >> > >> >> > > >> >> > > about new Java thread at the time of the
> >> > >> >> AttachCurrentThread call.
> >> > >> >> > > >> >> > >
> >> > >> >> > > >> >> > > >
> >> > >> >> > > >> >> > > > > Do you think it makes sense to replace a single
> >> > >> >> jthread
> >> > >> >> > > >> >> parameter with
> >> > >> >> > > >> >> > > > > a variety of stuff (like thread group,
> >> name)? It
> >> > >> >> seems the
> >> > >> >> > > >> only
> >> > >> >> > > >> >> > > > > purpose of at these args is to be passed
> >> back to
> >> > >> >> VM for
> >> > >> >> > > >> >> > > > > vm_jthread_create(). I would suggest to change
> >> > >> >> this and try
> >> > >> >> > > >> doing
> >> > >> >> > > >> >> > > > > either of:
> >> > >> >> > > >> >> > > > > 1) Make signature of jthread_attach with 3
> >> args,
> >> > >> >> JavaVM,
> >> > >> >> > > >> >> jthread and the daemon.
> >> > >> >> > > >> >> > > > Why do you want to pass daemon to TM but thread's
> >> > >> >> name and
> >> > >> >> > > >> >> group. Just
> >> > >> >> > > >> >> > > > because current TM doesn't need such information?
> >> > >> >> What if it is
> >> > >> >> > > >> >> > > > required to get thread name later? Say by
> >> > >> introducing
> >> > >> >> > > >> >> > >
> >> > >> >> > > >> >> > > I imagine you need a daemon attribute since the TM
> >> > >> >> is still
> >> > >> >> > > >> managing
> >> > >> >> > > >> >> > > the thread daemonality. TM is not managing thread
> >> > >> >> name and group -
> >> > >> >> > > >> >> > > they are all kept on the Java level, hence passing
> >> > >> >> them may be
> >> > >> >> > > >> >> > > excessive.
> >> > >> >> > > >> >> > >
> >> > >> >> > > >> >> > > > jthread_get_name... What will you do in that
> >> case?
> >> > >> >> Let me
> >> > >> >> > > >> guess you
> >> > >> >> > > >> >> > > > will call j.l.Thread.getName. Right. Ok! In that
> >> > >> >> case I see no
> >> > >> >> > > >> >> > > > problems to call j.l.Thread.isDaemon. Do you
> >> > >> >> agree? So it
> >> > >> >> > > >> doesn't
> >> > >> >> > > >> >> > >
> >> > >> >> > > >> >> > > As I suggested earlier, the best way to handle
> >> > >> >> daemonality would
> >> > >> >> > > >> >> > > probably be in pure Java - in j.l.Thread (or
> >> > >> >> > > >> j.l.VMThreadManager) or
> >> > >> >> > > >> >> > > whatever. You already lifted it up to the jthread
> >> > >> >> level, but
> >> > >> >> > > >> what if
> >> > >> >> > > >> >> > > we can go a little bit higher...
> >> > >> >> > > >> >> > >
> >> > >> >> > > >> >> > > > seems to be a good design to pass only part of
> >> the
> >> > >> >> > > >> information to
> >> > >> >> > > >> >> > > > jthread_atach. Lets look at the signature of
> >> > >> >> > > >> >> AttachCurrentThread. It
> >> > >> >> > > >> >> > > > takes exactly these three parameters (daemon,
> >> > >> >> name, group)
> >> > >> >> > > >> >> passed as a
> >> > >> >> > > >> >> > > > structure. I was thinking about having exactly
> >> the
> >> > >> >> same
> >> > >> >> > > >> >> structure as
> >> > >> >> > > >> >> > > > third parameter of jthread_attach but it occured
> >> > >> >> to be more
> >> > >> >> > > >> >> convinient
> >> > >> >> > > >> >> > > > to pass them seperatly. Although I don't see
> >> > >> >> strong reasons
> >> > >> >> > > >> against
> >> > >> >> > > >> >> > > > having a structure a third parameter.
> >> > >> >> > > >> >> > >
> >> > >> >> > > >> >> > > I see. Acually, I would love to keep the
> >> > >> >> jthread_attach func-ty at
> >> > >> >> > > >> >> the
> >> > >> >> > > >> >> > > minimum level which will be needed to handle the
> >> > >> >> only data that TM
> >> > >> >> > > >> >> > > should be aware of. We need a formal boundary
> >> > >> >> between jthread
> >> > >> >> > > >> layer
> >> > >> >> > > >> >> > > and vmcore (otherwise jthread won't have a much of
> >> > >> >> sense, one may
> >> > >> >> > > >> >> > > consider it just as a convenience set of functions
> >> > >> >> in vmcore which
> >> > >> >> > > >> >> are
> >> > >> >> > > >> >> > > doing something with threading).
> >> > >> >> > > >> >> > >
> >> > >> >> > > >> >> > > >
> >> > >> >> > > >> >> > > > > 2) Move the implementation of vm_create_jtrhead
> >> > >> >> () to
> >> > >> >> > > >> >> > > > > thread_java_basic.c - could it be written in
> >> > >> >> pure JNI without
> >> > >> >> > > >> >> using
> >> > >> >> > > >> >> > > > > internal VM API like class_alloc_new_object()?
> >> > >> >> > > >> >> > > >
> >> > >> >> > > >> >> > > > Yes, this can be done but it doesn't fix the
> >> > >> >> problem. You still
> >> > >> >> > > >> >> need
> >> > >> >> > > >> >> > > > to know about internal constructor of j.l.Thread
> >> > >> >> > > >> >> > >
> >> > >> >> > > >> >> > > That's bad. Given what you said, now it seems that
> >> > >> >> the most
> >> > >> >> > > >> >> preferable
> >> > >> >> > > >> >> > > sequence for AttachCurrentThread impl still
> >> would be
> >> > >> >> like:
> >> > >> >> > > >> >> > > JNIEnv = vm_attach();
> >> > >> >> > > >> >> > > jthread = create_jthread(JNIenv)
> >> > >> >> > > >> >> > > jthread_attach(JNIEnv, jthread) // stores JNIEnv
> >> and
> >> > >> >> Hythread into
> >> > >> >> > > >> >> > > TLS, doesn't call vm_attach any longer.
> >> > >> >> > > >> >> > > - this is almost what we had from the beginning...
> >> > >> >> > > >> >> > >
> >> > >> >> > > >> >> > > Thanks,
> >> > >> >> > > >> >> > > Andrey.
> >> > >> >> > > >> >> > >
> >> > >> >> > > >> >> > > >
> >> > >> >> > > >> >> > > >
> >> > >> >> > > >> >> > > > Thanks
> >> > >> >> > > >> >> > > > Evgueni
> >> > >> >> > > >> >> > > > >
> >> > >> >> > > >> >> > > > >
> >> > >> >> > > >> >> > > > > Thanks,
> >> > >> >> > > >> >> > > > > Andrey.
> >> > >> >> > > >> >> > > > >
> >> > >> >> > > >> >> > > > > >
> >> > >> >> > > >> >> > > > > > Thank you
> >> > >> >> > > >> >> > > > > > Evgueni
> >> > >> >> > > >> >> > > > > >
> >> > >> >> > > >> >> > > > > > On 10/2/06, Evgueni Brevnov
> >> > >> >> <ev...@gmail.com>
> >> > >> >> > > >> wrote:
> >> > >> >> > > >> >> > > > > > > On 9/29/06, Andrey Chernyshev
> >> > >> >> <a....@gmail.com>
> >> > >> >> > > >> >> wrote:
> >> > >> >> > > >> >> > > > > > > > On 9/29/06, Evgueni Brevnov
> >> > >> >> <ev...@gmail.com>
> >> > >> >> > > >> >> wrote:
> >> > >> >> > > >> >> > > > > > > > > Artem,
> >> > >> >> > > >> >> > > > > > > > >
> >> > >> >> > > >> >> > > > > > > > > Thank you for your feedback.... find my
> >> > >> >> inlined.....
> >> > >> >> > > >> >> > > > > > > > >
> >> > >> >> > > >> >> > > > > > > > > On 9/29/06, Artem Aliev
> >> > >> >> <ar...@gmail.com> wrote:
> >> > >> >> > > >> >> > > > > > > > > > Evgueni,
> >> > >> >> > > >> >> > > > > > > > > >
> >> > >> >> > > >> >> > > > > > > > > > I got most of your changes, but still
> >> > >> >> disagree
> >> > >> >> > > >> with all
> >> > >> >> > > >> >> > > > > > > > > > hythread/jthread interface changes.
> >> > >> >> Could leave
> >> > >> >> > > >> >> interface unchanged.
> >> > >> >> > > >> >> > > > > > > > > > See following possible solutions,
> >> that
> >> > >> >> could solve
> >> > >> >> > > >> >> the same problems
> >> > >> >> > > >> >> > > > > > > > > > without interface changes.
> >> > >> >> > > >> >> > > > > > > > > >
> >> > >> >> > > >> >> > > > > > > > > >
> >> > >> >> > > >> >> > > > > > > > > > 1) daemon attribute is a java
> >> > >> >> specific. (Andrey
> >> > >> >> > > >> >> mentioned this already).
> >> > >> >> > > >> >> > > > > > > > > > Could you please move it back. to
> >> > >> >> the jthread
> >> > >> >> > > >> >> layer. It is better
> >> > >> >> > > >> >> > > > > > > > > > to rename
> >> > >> >> > > >> >> > > > > > > > > >
> >> > >> >> hythread_wait_for_all_nondaemon_threads() to
> >> > >> >> > > >> >> > > > > > > > > >
> >> > >> jthread_wait_for_all_nondaemon_threads().
> >> > >> >> > > >> >> > > > > > > > > Ok, I see no problems to move "daemon"
> >> > >> >> to java layer.
> >> > >> >> > > >> >> In that case:
> >> > >> >> > > >> >> > > > > > > > > 1) I will move
> >> > >> >> > > >> >> hythread_wait_for_all_nondaemon_threads() from
> >> > >> >> > > >> >> > > > > > > > > thread_init.c to one which implements
> >> > >> >> java layer.
> >> > >> >> > > >> >> > > > > > > > > 2) I will move daemon field from
> >> > >> >> HyThread structure.
> >> > >> >> > > >> >> > > > > > > > >
> >> > >> >> > > >> >> > > > > > > > > Agree?
> >> > >> >> > > >> >> > > > > > > >
> >> > >> >> > > >> >> > > > > > > > Sounds good to me.
> >> > >> >> > > >> >> > > > > > >
> >> > >> >> > > >> >> > > > > > > OK, will do that.
> >> > >> >> > > >> >> > > > > > >
> >> > >> >> > > >> >> > > > > > > >
> >> > >> >> > > >> >> > > > > > > >
> >> > >> >> > > >> >> > > > > > > > >
> >> > >> >> > > >> >> > > > > > > > > >
> >> > >> >> > > >> >> > > > > > > > > > 2) JavaVM could be retrieved from
> >> > >> >> JNIEnv by
> >> > >> >> > > >> >> jni_get_java_vm(). So
> >> > >> >> > > >> >> > > > > > > > > > let the jthread_create() and
> >> others to
> >> > >> >> use JNIEnv
> >> > >> >> > > >> >> (that is passed from
> >> > >> >> > > >> >> > > > > > > > > > java native method).
> >> > >> >> > > >> >> > > > > > > > > > The vm_attach could get old JNI env
> >> > >> >> and create new
> >> > >> >> > > >> >> one for the new thread.
> >> > >> >> > > >> >> > > > > > > > > > The first JNIEnv is created in
> >> > >> >> CreateVM call and
> >> > >> >> > > >> >> could be passed to
> >> > >> >> > > >> >> > > > > > > > > > the first thread at startup.
> >> > >> >> > > >> >> > > > > > > > > No, no, no. I completely disagree with
> >> > >> >> that!!! Why do
> >> > >> >> > > >> >> you like JNIEnv
> >> > >> >> > > >> >> > > > > > > > > but JavaVM. Why do you think that
> >> > >> >> passing JavaVM
> >> > >> >> > > >> >> instead of JNIEnv
> >> > >> >> > > >> >> > > > > > > > > makes TM less modular? I don't see any
> >> > >> >> difference
> >> > >> >> > > >> >> here.... It seems
> >> > >> >> > > >> >> > > > > > > > > for me like a big big hack to grab
> >> > >> >> JNIEnv from another
> >> > >> >> > > >> >> thread and pass
> >> > >> >> > > >> >> > > > > > > > > it to jthread_attach to perform
> >> > >> >> operations in the
> >> > >> >> > > >> >> current thread.
> >> > >> >> > > >> >> > > > > > > >
> >> > >> >> > > >> >> > > > > > > > TM needs to know JNIEnv, mainly for
> >> > >> >> managing the
> >> > >> >> > > >> >> references to
> >> > >> >> > > >> >> > > > > > > > objects, throwing exceptions and calling
> >> > >> >> run() method of
> >> > >> >> > > >> >> a new thread.
> >> > >> >> > > >> >> > > > > > > > JNI spec proposes that JNIEnv is valid
> >> > >> >> within the given
> >> > >> >> > > >> >> thread, this
> >> > >> >> > > >> >> > > > > > > > is why TM holds the JNIEnv pointer at the
> >> > >> >> moment. This
> >> > >> >> > > >> >> is why TM likes
> >> > >> >> > > >> >> > > > > > > > the JNIEnv.
> >> > >> >> > > >> >> > > > > > > >
> >> > >> >> > > >> >> > > > > > > > Having the JNIEnv, one is able to get
> >> > >> >> JavaVM but not
> >> > >> >> > > >> >> vise versa. This
> >> > >> >> > > >> >> > > > > > > > is why TM doesn't like the JavaVM :)
> >> > >> >> > > >> >> > > > > > > I see your point. Only one note this is
> >> true
> >> > >> >> for already
> >> > >> >> > > >> >> attached threads...
> >> > >> >> > > >> >> > > > > > >
> >> > >> >> > > >> >> > > > > > > >
> >> > >> >> > > >> >> > > > > > > > I agree with you that there is a design
> >> > >> >> flaw that the
> >> > >> >> > > >> >> JNIEnv is copied
> >> > >> >> > > >> >> > > > > > > > from the parent thread to a child thread
> >> > >> >> during thread
> >> > >> >> > > >> >> creation. I
> >> > >> >> > > >> >> > > > > > > > think it could be resolved via
> >> vm_attach()
> >> > >> >> hook - with
> >> > >> >> > > >> >> this event, VM
> >> > >> >> > > >> >> > > > > > > > might tell the TM what the JNIEnv pointer
> >> > >> >> for new thread
> >> > >> >> > > >> >> should be. I
> >> > >> >> > > >> >> > > > > > > > think you did that by extending the
> >> > >> >> vm_attach() call
> >> > >> >> > > >> >> with the JNIEnv**
> >> > >> >> > > >> >> > > > > > > > argument.
> >> > >> >> > > >> >> > > > > > > >
> >> > >> >> > > >> >> > > > > > > > What is not completely clear is, why do
> >> > >> >> you have to pass
> >> > >> >> > > >> >> the JavaVM
> >> > >> >> > > >> >> > > > > > > > forth and back, once from VM to TM, and
> >> > >> >> then back from
> >> > >> >> > > >> >> TM to VM again?
> >> > >> >> > > >> >> > > > > > > >
> >> > >> >> > > >> >> > > > > > > > If you need to know in jthread_attach,
> >> > >> >> which particular
> >> > >> >> > > >> >> VM vm_attach()
> >> > >> >> > > >> >> > > > > > > > event is coming from, you could have
> >> > >> >> vm_attach like
> >> > >> >> > > >> >> > > > > > > > vm_attach(JNIEnv* currentThreadEnv,
> >> > >> JNIEnv**
> >> > >> >> > > >> >> newThreadEnv).
> >> > >> >> > > >> >> > > > > > > I'm a little bit confused.....Current
> >> thread
> >> > >> >> hasn't been
> >> > >> >> > > >> >> attached yet.
> >> > >> >> > > >> >> > > > > > > So there is no JNIEnv for it yet. How it
> >> can
> >> > >> >> be passed as
> >> > >> >> > > >> >> the first
> >> > >> >> > > >> >> > > > > > > parameter to vm_attach()?
> >> > >> >> > > >> >> > > > > > >
> >> > >> >> > > >> >> > > > > > > > Then you will be always able to get the
> >> > >> >> JavaVM from the
> >> > >> >> > > >> >> JNIEnv.
> >> > >> >> > > >> >> > > > > > > > The only difference is that you are
> >> > >> >> currently doing
> >> > >> >> > > >> >> JNIEnv->JavaVM
> >> > >> >> > > >> >> > > > > > > > conversion in the VMThreadManager, but
> >> why
> >> > >> >> can't you
> >> > >> >> > > >> >> just do this in
> >> > >> >> > > >> >> > > > > > > > vm_attach() without changing the
> >> interface
> >> > >> >> of the TM?
> >> > >> >> > > >> >> > > > > > > > So far JavaVM really looks like an extra
> >> > >> >> knowledge that
> >> > >> >> > > >> >> TM doesn't
> >> > >> >> > > >> >> > > > > > > > have to be aware of.
> >> > >> >> > > >> >> > > > > > > >
> >> > >> >> > > >> >> > > > > > > > > Moreover there is no JNIEnv when main
> >> > >> >> thread attaches
> >> > >> >> > > >> >> to VM. So we
> >> > >> >> > > >> >> > > > > > > > > should either keep it as is or change
> >> > >> >> original design
> >> > >> >> > > >> >> of TM and attach
> >> > >> >> > > >> >> > > > > > > > > thread to VM before attaching it to TM.
> >> > >> >> In that case
> >> > >> >> > > >> >> we will have
> >> > >> >> > > >> >> > > > > > > > > valid JNIEnv which can be passed to
> >> > >> >> jthread_atatch. We
> >> > >> >> > > >> >> need to think
> >> > >> >> > > >> >> > > > > > > > > over it twice before changing
> >> > >> something....
> >> > >> >> > > >> >> > > > > > > >
> >> > >> >> > > >> >> > > > > > > > Right. For jthread_attach, JNIenv
> >> needs to
> >> > >> >> be changed
> >> > >> >> > > >> >> from being input
> >> > >> >> > > >> >> > > > > > > > parameter to being the output parameter.
> >> > >> >> The way how
> >> > >> >> > > >> >> JNIenv is
> >> > >> >> > > >> >> > > > > > > > obtained by TM should be vm_attach()
> >> > >> event.
> >> > >> >> > > >> >> > > > > > > OK, JNIEnv is output parameter. And it
> >> > >> >> obtained by
> >> > >> >> > > >> >> vm_attach(). This
> >> > >> >> > > >> >> > > > > > > is exactly like I do in the patch. What I
> >> > >> >> don't understand
> >> > >> >> > > >> >> is how
> >> > >> >> > > >> >> > > > > > > jthread_attach knows to which VM the thread
> >> > >> >> should be
> >> > >> >> > > >> >> attached? Do you
> >> > >> >> > > >> >> > > > > > > suggest calling vm_attach first to create
> >> > >> >> JNIEnv it pass
> >> > >> >> > > >> >> it to
> >> > >> >> > > >> >> > > > > > > jthread_attach?
> >> > >> >> > > >> >> > > > > > >
> >> > >> >> > > >> >> > > > > > > >
> >> > >> >> > > >> >> > > > > > > > >
> >> > >> >> > > >> >> > > > > > > > >
> >> > >> >> > > >> >> > > > > > > > >
> >> > >> >> > > >> >> > > > > > > > > >
> >> > >> >> > > >> >> > > > > > > > > >
> >> > >> >> > > >> >> > > > > > > > > > 4) Original classlib hythread do
> >> > >> not use
> >> > >> >> > > >> >> hythread_library_t in arguments,
> >> > >> >> > > >> >> > > > > > > > > > It uses following code:
> >> > >> >> > > >> >> > > > > > > > > >
> >> > >> >> > > >> >> > > > > > > > > > hythread_library_t lib = GLOBAL_DATA
> >> > >> >> > > >> >> (default_library);
> >> > >> >> > > >> >> > > > > > > > > > or
> >> > >> >> > > >> >> > > > > > > > > > hythread_library_t library = thread-
> >> > >> >> >library;
> >> > >> >> > > >> >> > > > > > > > > >
> >> > >> >> > > >> >> > > > > > > > > > So could you please use the same
> >> > >> >> mechanism and
> >> > >> >> > > >> >> remove hythread_*_ex >functions.
> >> > >> >> > > >> >> > > > > > > > > Let's see if classlib's hythread needs
> >> > >> >> changing first.
> >> > >> >> > > >> >> It seems for me
> >> > >> >> > > >> >> > > > > > > > > such code prevents us from having
> >> > >> multi VM.
> >> > >> >> > > >> >> > > > > > > > >
> >> > >> >> > > >> >> > > > > > > > > >
> >> > >> >> > > >> >> > > > > > > > > > 5. You introduce more then one jni
> >> > >> >> env, but still
> >> > >> >> > > >> >> use global variable for it.
> >> > >> >> > > >> >> > > > > > > > > > So all changes like following:
> >> > >> >> > > >> >> > > > > > > > > > - JNIEnv *jenv = (JNIEnv*)
> >> > >> >> jni_native_intf;
> >> > >> >> > > >> >> > > > > > > > > > + JNIEnv *jenv = jni_native_intf;
> >> > >> >> > > >> >> > > > > > > > > >
> >> > >> >> > > >> >> > > > > > > > > > should be like:
> >> > >> >> > > >> >> > > > > > > > > > - JNIEnv *jenv = (JNIEnv*)
> >> > >> >> jni_native_intf;
> >> > >> >> > > >> >> > > > > > > > > > + JNIEnv *jenv = get_jni_env
> >> > >> >> (jthread_self());
> >> > >> >> > > >> >> > > > > > > > >
> >> > >> >> > > >> >> > > > > > > > > Ok, I see. I agree that global
> >> > >> >> jni_native_intf should
> >> > >> >> > > >> >> not be used.
> >> > >> >> > > >> >> > > > > > > > > There was simple reason why I altered
> >> > >> >> such lines.
> >> > >> >> > > >> >> Because I changed
> >> > >> >> > > >> >> > > > > > > > > the type of jni_native_intf and no
> >> > >> >> casting operator
> >> > >> >> > > >> >> is needed now. To
> >> > >> >> > > >> >> > > > > > > > > be honest I think get_jni_env
> >> > >> >> (jthread_self()) can be
> >> > >> >> > > >> >> good as temporary
> >> > >> >> > > >> >> > > > > > > > > solution only. Lets wait for design of
> >> > >> >> multi VM and
> >> > >> >> > > >> >> fix it according
> >> > >> >> > > >> >> > > > > > > > > to it.
> >> > >> >> > > >> >> > > > > > > >
> >> > >> >> > > >> >> > > > > > > > While we are in JNI code, we always have
> >> > >> >> the JNIenv (at
> >> > >> >> > > >> >> least
> >> > >> >> > > >> >> > > > > > > > initially it comes from Java code). If we
> >> > >> >> consider VM
> >> > >> >> > > >> >> code as if it
> >> > >> >> > > >> >> > > > > > > > was a JNI application, then it seems like
> >> > >> >> we should be
> >> > >> >> > > >> >> just passing
> >> > >> >> > > >> >> > > > > > > > JNIEnv as a parameter to all functions in
> >> > >> >> VM. Or, we can
> >> > >> >> > > >> >> be taking it
> >> > >> >> > > >> >> > > > > > > > from TLS (via jthread_self()), depending
> >> > >> >> on which way is
> >> > >> >> > > >> >> faster...
> >> > >> >> > > >> >> > > > > > > Agree.
> >> > >> >> > > >> >> > > > > > >
> >> > >> >> > > >> >> > > > > > > >
> >> > >> >> > > >> >> > > > > > > > >
> >> > >> >> > > >> >> > > > > > > > > >
> >> > >> >> > > >> >> > > > > > > > > > 6). And small remarks:
> >> > >> >> > > >> >> > > > > > > > > > +jint vm_init1(JavaVM_Internal *
> >> > >> java_vm,
> >> > >> >> > > >> >> JavaVMInitArgs * vm_arguments);
> >> > >> >> > > >> >> > > > > > > > > > +jint vm_init2(JNIEnv_Internal *
> >> > >> >> jni_env);
> >> > >> >> > > >> >> > > > > > > > > > Could you make names more meaningful,
> >> > >> >> then 1,2,3...?
> >> > >> >> > > >> >> > > > > > > > > Ok, will do that.
> >> > >> >> > > >> >> > > > > > > > >
> >> > >> >> > > >> >> > > > > > > > > >
> >> > >> >> > > >> >> > > > > > > > > > class VM_thread {
> >> > >> >> > > >> >> > > > > > > > > > ...
> >> > >> >> > > >> >> > > > > > > > > > + JNIEnv_Internal * jni_env;
> >> > >> >> > > >> >> > > > > > > > > > The jthread already has the jni_env
> >> > >> >> pointer, you do
> >> > >> >> > > >> >> not need to
> >> > >> >> > > >> >> > > > > > > > > > duplicate it here.
> >> > >> >> > > >> >> > > > > > > > > > forexample by using
> >> > >> >> > > >> >> jthread_get_JNI_env(jthread_self());
> >> > >> >> > > >> >> > > > > > > > >
> >> > >> >> > > >> >> > > > > > > > > Yes I know. I don't see any problems
> >> > >> >> here. Some times
> >> > >> >> > > >> >> it is much more
> >> > >> >> > > >> >> > > > > > > > > convenient to get JNIEnv from VM_thread
> >> > >> >> structure (and
> >> > >> >> > > >> >> faster) instead
> >> > >> >> > > >> >> > > > > > > > > of doing jthread_get_JNI_env
> >> > >> (jthread_self
> >> > >> >> ()). So I
> >> > >> >> > > >> >> need strong
> >> > >> >> > > >> >> > > > > > > > > arguments for removing it. Again it
> >> > >> >> seems that should
> >> > >> >> > > >> >> be addressed in
> >> > >> >> > > >> >> > > > > > > > > design of multi VM. So lets forget
> >> about
> >> > >> >> it for a
> >> > >> >> > > >> >> while...
> >> > >> >> > > >> >> > > > > > > >
> >> > >> >> > > >> >> > > > > > > > I think that the data duplication would
> >> > >> >> always serve as
> >> > >> >> > > >> >> a potential
> >> > >> >> > > >> >> > > > > > > > source of errors - while updating one
> >> copy
> >> > >> >> of object,
> >> > >> >> > > >> >> you may forget
> >> > >> >> > > >> >> > > > > > > > to update the other, often resulting into
> >> > >> >> a strange
> >> > >> >> > > >> >> behavior of the
> >> > >> >> > > >> >> > > > > > > > whole application. Let's see what are the
> >> > >> >> specific
> >> > >> >> > > >> >> performance
> >> > >> >> > > >> >> > > > > > > > concerns that have to be addressed. To
> >> get
> >> > >> >> VM_thread
> >> > >> >> > > >> >> structure, you
> >> > >> >> > > >> >> > > > > > > > would eventually go to the TLS, just like
> >> > >> >> > > >> >> > > > > > > > jthread_get_JNI_env(jthread_self()
> >> > >> would do.
> >> > >> >> > > >> >> > > > > > > If there is already VM_thread structure for
> >> > >> >> some reasons
> >> > >> >> > > >> >> then there
> >> > >> >> > > >> >> > > > > > > will be no extra access to TLS. It is
> >> > >> >> definitely much
> >> > >> >> > > >> more in
> >> > >> >> > > >> >> > > > > > > jthread_get_JNI_env(jthread_self() than
> >> just
> >> > >> >> one TLS
> >> > >> >> > > >> >> access and one
> >> > >> >> > > >> >> > > > > > > dereferncing. I don't think it is a really
> >> > >> >> big problem
> >> > >> >> > > >> >> now. Do you
> >> > >> >> > > >> >> > > > > > > agree to look at this later. I guess
> >> > >> multi VM
> >> > >> >> > > >> >> implementation will
> >> > >> >> > > >> >> > > > > > > alter it in any case.
> >> > >> >> > > >> >> > > > > > >
> >> > >> >> > > >> >> > > > > > > Thanks
> >> > >> >> > > >> >> > > > > > > Evgueni
> >> > >> >> > > >> >> > > > > > >
> >> > >> >> > > >> >> > > > > > > >
> >> > >> >> > > >> >> > > > > > > > Thanks,
> >> > >> >> > > >> >> > > > > > > > Andrey.
> >> > >> >> > > >> >> > > > > > > >
> >> > >> >> > > >> >> > > > > > > > >
> >> > >> >> > > >> >> > > > > > > > > Evgueni
> >> > >> >> > > >> >> > > > > > > > > >
> >> > >> >> > > >> >> > > > > > > > > > Thanks
> >> > >> >> > > >> >> > > > > > > > > > Artem
> >> > >> >> > > >> >> > > > > > > > > >
> >> > >> >> > > >> >> > > > > > > > > > On 9/28/06, Evgueni Brevnov
> >> > >> >> > > >> >> <ev...@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.
> >> > >> >> > > >> >> > > > > > > > > > >
> >> > >> >> > > >> >> > > > > > > > > > > Thanks
> >> > >> >> > > >> >> > > > > > > > > > > Evgueni
> >> > >> >> > > >> >> > > > > > > > > > >
> >> > >> >> > > >> >> > > > > > > > > > > On 9/28/06, Geir Magnusson Jr.
> >> > >> >> <ge...@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
> >> > >> >> > > >> >> <we...@gmail.com> wrote:
> >> > >> >> > > >> >> > > > > > > > > > > > >> On 9/26/06, Evgueni Brevnov
> >> > >> >> > > >> >> <ev...@gmail.com> wrote:
> >> > >> >> > > >> >> > > > > > > > > > > > >> >
> >> > >> >> > > >> >> > > > > > > > > > > > >> > On 9/27/06, Andrey
> >> Chernyshev
> >> > >> >> > > >> >> <a....@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
> >> > >> >> > > >> >> > > > > > > > > > >
> >> > >> >> > > >> >> > > > > > > > > > >
> >> > >> >> > > >> >> > > > > > > > > >
> >> > >> >> > > >> >> > > > > > > > > >
> >> > >> >> > > >> >>
> >> > >> >>
> >> > >>
> >> ---------------------------------------------------------------------
> >> > >> >> > > >> >> > > > > > > > > > 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
> >> > >> >> > > >> >> > > > > > > > >
> >> > >> >> > > >> >> > > > > > > > >
> >> > >> >> > > >> >> > > > > > > >
> >> > >> >> > > >> >> > > > > > > >
> >> > >> >> > > >> >> > > > > > > > --
> >> > >> >> > > >> >> > > > > > > > Andrey Chernyshev
> >> > >> >> > > >> >> > > > > > > > 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
> >> > >> >> > > >> >> > > > > >
> >> > >> >> > > >> >> > > > > >
> >> > >> >> > > >> >> > > > >
> >> > >> >> > > >> >> > > > >
> >> > >> >> > > >> >> > > > > --
> >> > >> >> > > >> >> > > > > Andrey Chernyshev
> >> > >> >> > > >> >> > > > > 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
> >> > >> >> > > >> >> > > >
> >> > >> >> > > >> >> > > >
> >> > >> >> > > >> >> > >
> >> > >> >> > > >> >> > >
> >> > >> >> > > >> >> > > --
> >> > >> >> > > >> >> > > Andrey Chernyshev
> >> > >> >> > > >> >> > > 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
> >> > >> >> > > >>
> >> > >> >> > > >>
> >> > >> >> > > >
> >> > >> >> > > >
> >> > >> >>
> >> > >>
> >> ---------------------------------------------------------------------
> >> > >> >> > > > 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
> >> > >> >
> >> > >>
> >> > >>
> >> > >>
> >> ---------------------------------------------------------------------
> >> > >> 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
> >> >
> >> >
> >>
> >
> > ---------------------------------------------------------------------
> > 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
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
ok - I just passed a smoke test, gc.PhantomReferenceQueueTest, that was
failing. We should look at that and see why it's so flakey.
If this works, I'm going to commit this thing so we can move forward.
We should focus on stablizing the c-unit tests, btw...
geir
Geir Magnusson Jr. wrote:
>
>
> Evgueni Brevnov wrote:
>> Geir, Salikh,
>>
>> cunit tests are very unstable...... that's why we have different
>> results on different platforms. It all tests problems. I already fixed
>> several places but it seems there is much more left. I believe we need
>> to revise them all. The main problem is that sleep(somthing) is used
>> to synchronize different threads. Sometimes there is no synchraniztion
>> at all. I propouse for switching it off until they get stable.
>> Can we do it?
>
> No. They all pass for me now, and I think that they are important as
> they are better than nothing.
>
> I suspected that these were just timing issues - we should just hunker
> down and get them fixed ASAP. We're making progress
>
> geir
>
>>
>> Evgueni
>>
>> On 10/9/06, Evgueni Brevnov <ev...@gmail.com> wrote:
>>> Could you insert sleep_a_click(); just before line 59 right after
>>> hysem_create(&start, 0, 1):
>>>
>>> Does it help?
>>>
>>> On 10/9/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>>> > [echo] ## Executing C unit test: test_ti_instrum
>>> > [exec] Result: 1
>>> > [echo] INFO: TEST test_jthread_get_all_threads start
>>> > [echo] ERROR: Assertion '(thread_count)==(i +
>>> > initial_thread_count)' failed at /home/geir/dev/apache/harmony/
>>> > enhanced/trunk/working_vm/vm/tes
>>> > ts/unit/thread/test_ti_instrum.c:94
>>> > [echo] Init1: initial_thread_count=1, initial_all_threads_count=1
>>> > [echo] Init3: initial_thread_count=1, initial_all_threads_count=1
>>> > [echo] Init3: thread_count=3, all_threads_count=3
>>> > [echo] INFO: TEST test_jthread_get_all_threads: FAILED
>>> > [echo] INFO: TEST test_jthread_get_thread_count start
>>> > [echo] Init1: initial_thread_count=3, initial_all_threads_count=3
>>> > [echo] INFO: TEST test_jthread_get_thread_count: PASSED
>>> > [echo] INFO: TEST test_jthread_get_blocked_count start
>>> > [echo] INFO: TEST test_jthread_get_blocked_count: PASSED
>>> > [echo] ## TEST FAILED
>>> >
>>> >
>>> > On Oct 9, 2006, at 12:35 AM, Evgueni Brevnov wrote:
>>> >
>>> > > I put debug printing into test_ti_instrum.c and attached it to JIRA.
>>> > > Could you run it on your machine and send me console output.
>>> > >
>>> > > Evgueni
>>> > >
>>> > > On 10/9/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>>> > >> I keep getting a failure when running the tests -
>>> > >>
>>> > >> test_jthread_get_all-threads failling the assertion at
>>> > >> test_ti_instrum.c:80
>>> > >>
>>> > >> geir
>>> > >>
>>> > >> On Oct 8, 2006, at 7:19 AM, Evgueni Brevnov wrote:
>>> > >>
>>> > >> > While running cunit on Linux it turned out one test case fails
>>> some
>>> > >> > time. The fix is in tests.final.2.patch.
>>> > >> >
>>> > >> > So the last versions to be committed:
>>> > >> > invocation_api.final.patch
>>> > >> > build.final.2.patch
>>> > >> > tests.final.2.patch
>>> > >> >
>>> > >> > Evgueni
>>> > >> >
>>> > >> >
>>> > >> > On 10/8/06, Evgueni Brevnov <ev...@gmail.com> wrote:
>>> > >> >> I mahaged to resolve the problem on Linux.... will update
>>> > >> >> build.final.patch with build.final.2.patch in a while
>>> > >> >>
>>> > >> >> On 10/8/06, Evgueni Brevnov <ev...@gmail.com> wrote:
>>> > >> >> > Hi,
>>> > >> >> >
>>> > >> >> > Oh! Ooh! I did that..... I passed cunit, somke, kernel
>>> tests on
>>> > >> >> > Windows and smoke, kernel tests on Linux. Unfortunately I
>>> > >> failed to
>>> > >> >> > link cunit tests on Linux so far. So I disabled cunit on Linux
>>> > >> >> until
>>> > >> >> > the problem is solved. I believe it is acceptable as short
>>> term
>>> > >> >> > solution. I found several problems in cunit tests. I will come
>>> > >> >> up with
>>> > >> >> > my findings later (not today).
>>> > >> >> >
>>> > >> >> > Use latest patches from HARMONY-1582. They are marked as
>>> final.
>>> > >> >> There
>>> > >> >> > are three patches. One for build module, one for cunit
>>> tests and
>>> > >> >> one
>>> > >> >> > for VM itself.
>>> > >> >> >
>>> > >> >> > Thanks
>>> > >> >> > Evgueni
>>> > >> >> >
>>> > >> >> >
>>> > >> >> > On 10/6/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>>> > >> >> > > Nooooooo! LOL
>>> > >> >> > >
>>> > >> >> > > I'm here waiting - This will unblock a whole bunch of
>>> > >> things :)
>>> > >> >> > >
>>> > >> >> > > Thanks for the effort
>>> > >> >> > >
>>> > >> >> > > Evgueni Brevnov wrote:
>>> > >> >> > > > Geir,
>>> > >> >> > > >
>>> > >> >> > > > That's terrible. We have power outage....servers are
>>> down. I
>>> > >> >> can't
>>> > >> >> > > > send the patches now.... will do it tomorrow
>>> > >> >> > > >
>>> > >> >> > > > Evgueni
>>> > >> >> > > > On 10/5/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>>> > >> >> > > >> woo hoo! here we go...
>>> > >> >> > > >>
>>> > >> >> > > >>
>>> > >> >> > > >> Andrey Chernyshev wrote:
>>> > >> >> > > >> > Hi Evgueni,
>>> > >> >> > > >> >
>>> > >> >> > > >> > On 10/4/06, Evgueni Brevnov <ev...@gmail.com>
>>> > >> >> wrote:
>>> > >> >> > > >> >> Hi All,
>>> > >> >> > > >> >>
>>> > >> >> > > >> >> I have attached updated patch to the JIRA. It should
>>> > >> >> resolve remain
>>> > >> >> > > >> >> concerns. Andrey, could you give a green light now?
>>> > >> >> > > >> >
>>> > >> >> > > >> > Thanks for updating the patch! I agree it it can be
>>> > >> >> committed, at
>>> > >> >> > > >> > least signatures look good. 5 revisions seem like more
>>> > >> >> than enough :).
>>> > >> >> > > >> > Anyways, I think the remaining issues can be resolved
>>> > >> >> with additional
>>> > >> >> > > >> > patches. Thanks again for the good work and your
>>> > >> patience.
>>> > >> >> > > >> >
>>> > >> >> > > >> > Thanks,
>>> > >> >> > > >> > Andrey.
>>> > >> >> > > >> >
>>> > >> >> > > >> >>
>>> > >> >> > > >> >> Thanks
>>> > >> >> > > >> >> Evgueni
>>> > >> >> > > >> >>
>>> > >> >> > > >> >> On 10/4/06, Evgueni Brevnov
>>> <ev...@gmail.com>
>>> > >> >> wrote:
>>> > >> >> > > >> >> > Andrey,
>>> > >> >> > > >> >> >
>>> > >> >> > > >> >> > I see your points. I think both approaches have
>>> > >> >> advantages and
>>> > >> >> > > >> >> > disadvantages. I think it is quite hard to say which
>>> > >> >> approach is
>>> > >> >> > > >> >> > better until we play with one VM only. I still feel
>>> > >> >> like introducing
>>> > >> >> > > >> >> > one more dependence is better than spreading code
>>> > >> >> which deals with
>>> > >> >> > > >> >> > attachment among VM and TM. We really get stuck. OK,
>>> > >> >> just because I
>>> > >> >> > > >> >> > want to move forward I will do required changes to
>>> > >> remove
>>> > >> >> > > >> >> > vm_create_jthread from TM. I believe that will
>>> resolve
>>> > >> >> all our
>>> > >> >> > > >> >> > disagreements and the patch will be applied soon.
>>> > >> >> > > >> >> >
>>> > >> >> > > >> >> >
>>> > >> >> > > >> >> > Thanks
>>> > >> >> > > >> >> > Evgueni.
>>> > >> >> > > >> >> >
>>> > >> >> > > >> >> > On 10/4/06, Andrey Chernyshev
>>> > >> >> <a....@gmail.com> wrote:
>>> > >> >> > > >> >> > > On 10/3/06, Evgueni Brevnov
>>> > >> >> <ev...@gmail.com> wrote:
>>> > >> >> > > >> >> > > > On 10/3/06, Andrey Chernyshev
>>> > >> >> <a....@gmail.com> wrote:
>>> > >> >> > > >> >> > > > > On 10/2/06, Evgueni Brevnov
>>> > >> >> <ev...@gmail.com> wrote:
>>> > >> >> > > >> >> > > > > > Andrey,
>>> > >> >> > > >> >> > > > > >
>>> > >> >> > > >> >> > > > > > Just to be clear.... I agree with you it is
>>> > >> more
>>> > >> >> > > >> convenient if
>>> > >> >> > > >> >> > > > > > jthread_create takes JNIEnv instead of
>>> > >> JavaVM. It
>>> > >> >> > > >> reflects that
>>> > >> >> > > >> >> > > > > > current thread has been attached already. Do
>>> > >> >> you think it
>>> > >> >> > > >> >> makes sense
>>> > >> >> > > >> >> > > > > > to get rid of JNIEnv and use
>>> > >> >> jthread_get_JNI_env in that
>>> > >> >> > > >> case?
>>> > >> >> > > >> >> > > > >
>>> > >> >> > > >> >> > > > > The jthread_* layer is designed like if it
>>> were
>>> > >> >> a regular JNI
>>> > >> >> > > >> >> > > > > application which is meant to be called
>>> from the
>>> > >> >> Java code,
>>> > >> >> > > >> hence
>>> > >> >> > > >> >> > > > > every function on that layer receives
>>> JNIenv. We
>>> > >> >> can probably
>>> > >> >> > > >> >> get rid
>>> > >> >> > > >> >> > > > > of the JNEnv parameter for jthread_*
>>> functions,
>>> > >> >> assuming that
>>> > >> >> > > >> >> TM can
>>> > >> >> > > >> >> > > > > always extract JNIenv for the current thread
>>> > >> with
>>> > >> >> > > >> >> > > > > jthread_get_JNI_env().
>>> > >> >> > > >> >> > > > > My only concern would be the performance -
>>> once
>>> > >> >> the JNIenv is
>>> > >> >> > > >> >> already
>>> > >> >> > > >> >> > > > > known for the native part of the kernel
>>> classes
>>> > >> >> impl, it
>>> > >> >> > > >> must be
>>> > >> >> > > >> >> > > > > cheaper to pass JNIEnv to TM as an extra
>>> > >> >> parameter rather than
>>> > >> >> > > >> >> extract
>>> > >> >> > > >> >> > > > > it from the TLS again.
>>> > >> >> > > >> >> > > > > Other than that, I see no strong advantages in
>>> > >> >> keeping JNIEnv
>>> > >> >> > > >> >> parameter.
>>> > >> >> > > >> >> > > > >
>>> > >> >> > > >> >> > > > >
>>> > >> >> > > >> >> > > > > > Regarding jthread_attach. I still didn't get
>>> > >> >> your point....
>>> > >> >> > > >> >> Clarify it
>>> > >> >> > > >> >> > > > > > please if you think jhread_attach should be
>>> > >> >> modified.
>>> > >> >> > > >> >> > > > >
>>> > >> >> > > >> >> > > > > Sorry for being not clear: I think for
>>> > >> >> jthread_attach, we have
>>> > >> >> > > >> >> two options:
>>> > >> >> > > >> >> > > > > 1) Make JNIEnv input parameter - it must be
>>> new
>>> > >> >> JNIEnv that VM
>>> > >> >> > > >> >> > > > > pre-allocates for the new Java thread.
>>> > >> >> jthread_attach
>>> > >> >> > > >> would just
>>> > >> >> > > >> >> > > > > associate it with the current thread.
>>> > >> >> > > >> >> > > > >
>>> > >> >> > > >> >> > > > > 2) Obtain JNIEnv via vm_attach() callback. In
>>> > >> >> this case, if
>>> > >> >> > > >> >> > > > > vm_attach() callback implementation needs to
>>> > >> >> know for which
>>> > >> >> > > >> >> JavaVM new
>>> > >> >> > > >> >> > > > > JNIenv has to be allocated, then we'll need to
>>> > >> >> add JavaVM as
>>> > >> >> > > >> >> input
>>> > >> >> > > >> >> > > > > parameter for jthread_attach().
>>> > >> >> > > >> >> > > > > I think both options should be fine, (1) would
>>> > >> >> probably
>>> > >> >> > > >> keep TM
>>> > >> >> > > >> >> > > > > interface a bit lighter, though (2) may look
>>> > >> >> more closer to
>>> > >> >> > > >> >> the JNI
>>> > >> >> > > >> >> > > > > invocation API idea.
>>> > >> >> > > >> >> > > > > So I think adding JavaVM specifically for
>>> > >> >> jthread_attach
>>> > >> >> > > >> may make
>>> > >> >> > > >> >> > > > > sense given the explanation you provided
>>> > >> earlier.
>>> > >> >> > > >> >> > > > >
>>> > >> >> > > >> >> > > > > The concern I would have regarding the
>>> proposed
>>> > >> >> jthread_attach
>>> > >> >> > > >> >> > > > > implementation is a call to
>>> vm_create_jthread()
>>> > >> >> - this call
>>> > >> >> > > >> >> introduces
>>> > >> >> > > >> >> > > > > an extra dependency of TM on vmcore that I'd
>>> > >> >> prefer to be
>>> > >> >> > > >> >> avoided. In
>>> > >> >> > > >> >> > > > > the original version, jthread_attach() was
>>> > >> >> taking jthread
>>> > >> >> > > >> >> argument of
>>> > >> >> > > >> >> > > > > the already prepared j.l.Thread.
>>> > >> >> > > >> >> > > >
>>> > >> >> > > >> >> > > > I understand your concern. Unfortunately I don't
>>> > >> >> see what we
>>> > >> >> > > >> can do
>>> > >> >> > > >> >> > > > here. Let me explain. In the beginning you
>>> have an
>>> > >> >> unattached
>>> > >> >> > > >> >> native
>>> > >> >> > > >> >> > > > thread. To be able to call java code (which is
>>> > >> >> required for
>>> > >> >> > > >> >> > > > constructing j.l.Thread instance) the thread
>>> > >> >> should be attached
>>> > >> >> > > >> >> first.
>>> > >> >> > > >> >> > > > To be specific it should be attached to VM by
>>> > >> >> calling vm_attach
>>> > >> >> > > >> >> which
>>> > >> >> > > >> >> > > > will return a valid JNIEnv It is valid to use
>>> JNI
>>> > >> >> from that
>>> > >> >> > > >> moment.
>>> > >> >> > > >> >> > > > Obtained JNIEnv can be used to execute java code
>>> > >> >> and create
>>> > >> >> > > >> >> j.l.Thread
>>> > >> >> > > >> >> > > > instance. Since we do vm_attach in
>>> jthread_attach
>>> > >> >> we need to do
>>> > >> >> > > >> >> > > > vm_create_jthread inside jthread_atach as well.
>>> > >> >> > > >> >> > > > Of course it can be an alternative to do
>>> vm_attach
>>> > >> >> and
>>> > >> >> > > >> >> > > > vm_create_jthread outside of TM right before
>>> > >> >> jthread_attach.
>>> > >> >> > > >> >> Sure it
>>> > >> >> > > >> >> > > > will reduce one dependence between VM and TM.
>>> But
>>> > >> >> it seems like
>>> > >> >> > > >> >> > > > artificial action for me just because of
>>> > >> >> dependency....
>>> > >> >> > > >> >> > >
>>> > >> >> > > >> >> > > Why do you think it is artificial? I would rather
>>> > >> >> prefer not to
>>> > >> >> > > >> throw
>>> > >> >> > > >> >> > > vm_attach event from the jthread_attach() call at
>>> > >> >> all than to add
>>> > >> >> > > >> >> > > extra dependency. The idea of jthread layer is a
>>> > >> >> Java face to
>>> > >> >> > > >> >> > > hythread, it is meant to know either a little or
>>> > >> >> nothing about the
>>> > >> >> > > >> >> > > rest of VM. It may be logical to throw vm_attach
>>> > >> >> call from the
>>> > >> >> > > >> newly
>>> > >> >> > > >> >> > > created thread, because there is no other way
>>> to let
>>> > >> >> know VM
>>> > >> >> > > >> the new
>>> > >> >> > > >> >> > > thread is created. VM attach is a different case -
>>> > >> >> VM already
>>> > >> >> > > >> knows
>>> > >> >> > > >> >> > > about new Java thread at the time of the
>>> > >> >> AttachCurrentThread call.
>>> > >> >> > > >> >> > >
>>> > >> >> > > >> >> > > >
>>> > >> >> > > >> >> > > > > Do you think it makes sense to replace a
>>> single
>>> > >> >> jthread
>>> > >> >> > > >> >> parameter with
>>> > >> >> > > >> >> > > > > a variety of stuff (like thread group,
>>> name)? It
>>> > >> >> seems the
>>> > >> >> > > >> only
>>> > >> >> > > >> >> > > > > purpose of at these args is to be passed
>>> back to
>>> > >> >> VM for
>>> > >> >> > > >> >> > > > > vm_jthread_create(). I would suggest to change
>>> > >> >> this and try
>>> > >> >> > > >> doing
>>> > >> >> > > >> >> > > > > either of:
>>> > >> >> > > >> >> > > > > 1) Make signature of jthread_attach with 3
>>> args,
>>> > >> >> JavaVM,
>>> > >> >> > > >> >> jthread and the daemon.
>>> > >> >> > > >> >> > > > Why do you want to pass daemon to TM but
>>> thread's
>>> > >> >> name and
>>> > >> >> > > >> >> group. Just
>>> > >> >> > > >> >> > > > because current TM doesn't need such
>>> information?
>>> > >> >> What if it is
>>> > >> >> > > >> >> > > > required to get thread name later? Say by
>>> > >> introducing
>>> > >> >> > > >> >> > >
>>> > >> >> > > >> >> > > I imagine you need a daemon attribute since the TM
>>> > >> >> is still
>>> > >> >> > > >> managing
>>> > >> >> > > >> >> > > the thread daemonality. TM is not managing thread
>>> > >> >> name and group -
>>> > >> >> > > >> >> > > they are all kept on the Java level, hence passing
>>> > >> >> them may be
>>> > >> >> > > >> >> > > excessive.
>>> > >> >> > > >> >> > >
>>> > >> >> > > >> >> > > > jthread_get_name... What will you do in that
>>> case?
>>> > >> >> Let me
>>> > >> >> > > >> guess you
>>> > >> >> > > >> >> > > > will call j.l.Thread.getName. Right. Ok! In that
>>> > >> >> case I see no
>>> > >> >> > > >> >> > > > problems to call j.l.Thread.isDaemon. Do you
>>> > >> >> agree? So it
>>> > >> >> > > >> doesn't
>>> > >> >> > > >> >> > >
>>> > >> >> > > >> >> > > As I suggested earlier, the best way to handle
>>> > >> >> daemonality would
>>> > >> >> > > >> >> > > probably be in pure Java - in j.l.Thread (or
>>> > >> >> > > >> j.l.VMThreadManager) or
>>> > >> >> > > >> >> > > whatever. You already lifted it up to the jthread
>>> > >> >> level, but
>>> > >> >> > > >> what if
>>> > >> >> > > >> >> > > we can go a little bit higher...
>>> > >> >> > > >> >> > >
>>> > >> >> > > >> >> > > > seems to be a good design to pass only part
>>> of the
>>> > >> >> > > >> information to
>>> > >> >> > > >> >> > > > jthread_atach. Lets look at the signature of
>>> > >> >> > > >> >> AttachCurrentThread. It
>>> > >> >> > > >> >> > > > takes exactly these three parameters (daemon,
>>> > >> >> name, group)
>>> > >> >> > > >> >> passed as a
>>> > >> >> > > >> >> > > > structure. I was thinking about having
>>> exactly the
>>> > >> >> same
>>> > >> >> > > >> >> structure as
>>> > >> >> > > >> >> > > > third parameter of jthread_attach but it occured
>>> > >> >> to be more
>>> > >> >> > > >> >> convinient
>>> > >> >> > > >> >> > > > to pass them seperatly. Although I don't see
>>> > >> >> strong reasons
>>> > >> >> > > >> against
>>> > >> >> > > >> >> > > > having a structure a third parameter.
>>> > >> >> > > >> >> > >
>>> > >> >> > > >> >> > > I see. Acually, I would love to keep the
>>> > >> >> jthread_attach func-ty at
>>> > >> >> > > >> >> the
>>> > >> >> > > >> >> > > minimum level which will be needed to handle the
>>> > >> >> only data that TM
>>> > >> >> > > >> >> > > should be aware of. We need a formal boundary
>>> > >> >> between jthread
>>> > >> >> > > >> layer
>>> > >> >> > > >> >> > > and vmcore (otherwise jthread won't have a much of
>>> > >> >> sense, one may
>>> > >> >> > > >> >> > > consider it just as a convenience set of functions
>>> > >> >> in vmcore which
>>> > >> >> > > >> >> are
>>> > >> >> > > >> >> > > doing something with threading).
>>> > >> >> > > >> >> > >
>>> > >> >> > > >> >> > > >
>>> > >> >> > > >> >> > > > > 2) Move the implementation of
>>> vm_create_jtrhead
>>> > >> >> () to
>>> > >> >> > > >> >> > > > > thread_java_basic.c - could it be written in
>>> > >> >> pure JNI without
>>> > >> >> > > >> >> using
>>> > >> >> > > >> >> > > > > internal VM API like class_alloc_new_object()?
>>> > >> >> > > >> >> > > >
>>> > >> >> > > >> >> > > > Yes, this can be done but it doesn't fix the
>>> > >> >> problem. You still
>>> > >> >> > > >> >> need
>>> > >> >> > > >> >> > > > to know about internal constructor of j.l.Thread
>>> > >> >> > > >> >> > >
>>> > >> >> > > >> >> > > That's bad. Given what you said, now it seems that
>>> > >> >> the most
>>> > >> >> > > >> >> preferable
>>> > >> >> > > >> >> > > sequence for AttachCurrentThread impl still
>>> would be
>>> > >> >> like:
>>> > >> >> > > >> >> > > JNIEnv = vm_attach();
>>> > >> >> > > >> >> > > jthread = create_jthread(JNIenv)
>>> > >> >> > > >> >> > > jthread_attach(JNIEnv, jthread) // stores
>>> JNIEnv and
>>> > >> >> Hythread into
>>> > >> >> > > >> >> > > TLS, doesn't call vm_attach any longer.
>>> > >> >> > > >> >> > > - this is almost what we had from the beginning...
>>> > >> >> > > >> >> > >
>>> > >> >> > > >> >> > > Thanks,
>>> > >> >> > > >> >> > > Andrey.
>>> > >> >> > > >> >> > >
>>> > >> >> > > >> >> > > >
>>> > >> >> > > >> >> > > >
>>> > >> >> > > >> >> > > > Thanks
>>> > >> >> > > >> >> > > > Evgueni
>>> > >> >> > > >> >> > > > >
>>> > >> >> > > >> >> > > > >
>>> > >> >> > > >> >> > > > > Thanks,
>>> > >> >> > > >> >> > > > > Andrey.
>>> > >> >> > > >> >> > > > >
>>> > >> >> > > >> >> > > > > >
>>> > >> >> > > >> >> > > > > > Thank you
>>> > >> >> > > >> >> > > > > > Evgueni
>>> > >> >> > > >> >> > > > > >
>>> > >> >> > > >> >> > > > > > On 10/2/06, Evgueni Brevnov
>>> > >> >> <ev...@gmail.com>
>>> > >> >> > > >> wrote:
>>> > >> >> > > >> >> > > > > > > On 9/29/06, Andrey Chernyshev
>>> > >> >> <a....@gmail.com>
>>> > >> >> > > >> >> wrote:
>>> > >> >> > > >> >> > > > > > > > On 9/29/06, Evgueni Brevnov
>>> > >> >> <ev...@gmail.com>
>>> > >> >> > > >> >> wrote:
>>> > >> >> > > >> >> > > > > > > > > Artem,
>>> > >> >> > > >> >> > > > > > > > >
>>> > >> >> > > >> >> > > > > > > > > Thank you for your feedback....
>>> find my
>>> > >> >> inlined.....
>>> > >> >> > > >> >> > > > > > > > >
>>> > >> >> > > >> >> > > > > > > > > On 9/29/06, Artem Aliev
>>> > >> >> <ar...@gmail.com> wrote:
>>> > >> >> > > >> >> > > > > > > > > > Evgueni,
>>> > >> >> > > >> >> > > > > > > > > >
>>> > >> >> > > >> >> > > > > > > > > > I got most of your changes, but
>>> still
>>> > >> >> disagree
>>> > >> >> > > >> with all
>>> > >> >> > > >> >> > > > > > > > > > hythread/jthread interface changes.
>>> > >> >> Could leave
>>> > >> >> > > >> >> interface unchanged.
>>> > >> >> > > >> >> > > > > > > > > > See following possible solutions,
>>> that
>>> > >> >> could solve
>>> > >> >> > > >> >> the same problems
>>> > >> >> > > >> >> > > > > > > > > > without interface changes.
>>> > >> >> > > >> >> > > > > > > > > >
>>> > >> >> > > >> >> > > > > > > > > >
>>> > >> >> > > >> >> > > > > > > > > > 1) daemon attribute is a java
>>> > >> >> specific. (Andrey
>>> > >> >> > > >> >> mentioned this already).
>>> > >> >> > > >> >> > > > > > > > > > Could you please move it back. to
>>> > >> >> the jthread
>>> > >> >> > > >> >> layer. It is better
>>> > >> >> > > >> >> > > > > > > > > > to rename
>>> > >> >> > > >> >> > > > > > > > > >
>>> > >> >> hythread_wait_for_all_nondaemon_threads() to
>>> > >> >> > > >> >> > > > > > > > > >
>>> > >> jthread_wait_for_all_nondaemon_threads().
>>> > >> >> > > >> >> > > > > > > > > Ok, I see no problems to move "daemon"
>>> > >> >> to java layer.
>>> > >> >> > > >> >> In that case:
>>> > >> >> > > >> >> > > > > > > > > 1) I will move
>>> > >> >> > > >> >> hythread_wait_for_all_nondaemon_threads() from
>>> > >> >> > > >> >> > > > > > > > > thread_init.c to one which implements
>>> > >> >> java layer.
>>> > >> >> > > >> >> > > > > > > > > 2) I will move daemon field from
>>> > >> >> HyThread structure.
>>> > >> >> > > >> >> > > > > > > > >
>>> > >> >> > > >> >> > > > > > > > > Agree?
>>> > >> >> > > >> >> > > > > > > >
>>> > >> >> > > >> >> > > > > > > > Sounds good to me.
>>> > >> >> > > >> >> > > > > > >
>>> > >> >> > > >> >> > > > > > > OK, will do that.
>>> > >> >> > > >> >> > > > > > >
>>> > >> >> > > >> >> > > > > > > >
>>> > >> >> > > >> >> > > > > > > >
>>> > >> >> > > >> >> > > > > > > > >
>>> > >> >> > > >> >> > > > > > > > > >
>>> > >> >> > > >> >> > > > > > > > > > 2) JavaVM could be retrieved from
>>> > >> >> JNIEnv by
>>> > >> >> > > >> >> jni_get_java_vm(). So
>>> > >> >> > > >> >> > > > > > > > > > let the jthread_create() and
>>> others to
>>> > >> >> use JNIEnv
>>> > >> >> > > >> >> (that is passed from
>>> > >> >> > > >> >> > > > > > > > > > java native method).
>>> > >> >> > > >> >> > > > > > > > > > The vm_attach could get old JNI env
>>> > >> >> and create new
>>> > >> >> > > >> >> one for the new thread.
>>> > >> >> > > >> >> > > > > > > > > > The first JNIEnv is created in
>>> > >> >> CreateVM call and
>>> > >> >> > > >> >> could be passed to
>>> > >> >> > > >> >> > > > > > > > > > the first thread at startup.
>>> > >> >> > > >> >> > > > > > > > > No, no, no. I completely disagree with
>>> > >> >> that!!! Why do
>>> > >> >> > > >> >> you like JNIEnv
>>> > >> >> > > >> >> > > > > > > > > but JavaVM. Why do you think that
>>> > >> >> passing JavaVM
>>> > >> >> > > >> >> instead of JNIEnv
>>> > >> >> > > >> >> > > > > > > > > makes TM less modular? I don't see any
>>> > >> >> difference
>>> > >> >> > > >> >> here.... It seems
>>> > >> >> > > >> >> > > > > > > > > for me like a big big hack to grab
>>> > >> >> JNIEnv from another
>>> > >> >> > > >> >> thread and pass
>>> > >> >> > > >> >> > > > > > > > > it to jthread_attach to perform
>>> > >> >> operations in the
>>> > >> >> > > >> >> current thread.
>>> > >> >> > > >> >> > > > > > > >
>>> > >> >> > > >> >> > > > > > > > TM needs to know JNIEnv, mainly for
>>> > >> >> managing the
>>> > >> >> > > >> >> references to
>>> > >> >> > > >> >> > > > > > > > objects, throwing exceptions and calling
>>> > >> >> run() method of
>>> > >> >> > > >> >> a new thread.
>>> > >> >> > > >> >> > > > > > > > JNI spec proposes that JNIEnv is valid
>>> > >> >> within the given
>>> > >> >> > > >> >> thread, this
>>> > >> >> > > >> >> > > > > > > > is why TM holds the JNIEnv pointer at
>>> the
>>> > >> >> moment. This
>>> > >> >> > > >> >> is why TM likes
>>> > >> >> > > >> >> > > > > > > > the JNIEnv.
>>> > >> >> > > >> >> > > > > > > >
>>> > >> >> > > >> >> > > > > > > > Having the JNIEnv, one is able to get
>>> > >> >> JavaVM but not
>>> > >> >> > > >> >> vise versa. This
>>> > >> >> > > >> >> > > > > > > > is why TM doesn't like the JavaVM :)
>>> > >> >> > > >> >> > > > > > > I see your point. Only one note this is
>>> true
>>> > >> >> for already
>>> > >> >> > > >> >> attached threads...
>>> > >> >> > > >> >> > > > > > >
>>> > >> >> > > >> >> > > > > > > >
>>> > >> >> > > >> >> > > > > > > > I agree with you that there is a design
>>> > >> >> flaw that the
>>> > >> >> > > >> >> JNIEnv is copied
>>> > >> >> > > >> >> > > > > > > > from the parent thread to a child thread
>>> > >> >> during thread
>>> > >> >> > > >> >> creation. I
>>> > >> >> > > >> >> > > > > > > > think it could be resolved via
>>> vm_attach()
>>> > >> >> hook - with
>>> > >> >> > > >> >> this event, VM
>>> > >> >> > > >> >> > > > > > > > might tell the TM what the JNIEnv
>>> pointer
>>> > >> >> for new thread
>>> > >> >> > > >> >> should be. I
>>> > >> >> > > >> >> > > > > > > > think you did that by extending the
>>> > >> >> vm_attach() call
>>> > >> >> > > >> >> with the JNIEnv**
>>> > >> >> > > >> >> > > > > > > > argument.
>>> > >> >> > > >> >> > > > > > > >
>>> > >> >> > > >> >> > > > > > > > What is not completely clear is, why do
>>> > >> >> you have to pass
>>> > >> >> > > >> >> the JavaVM
>>> > >> >> > > >> >> > > > > > > > forth and back, once from VM to TM, and
>>> > >> >> then back from
>>> > >> >> > > >> >> TM to VM again?
>>> > >> >> > > >> >> > > > > > > >
>>> > >> >> > > >> >> > > > > > > > If you need to know in jthread_attach,
>>> > >> >> which particular
>>> > >> >> > > >> >> VM vm_attach()
>>> > >> >> > > >> >> > > > > > > > event is coming from, you could have
>>> > >> >> vm_attach like
>>> > >> >> > > >> >> > > > > > > > vm_attach(JNIEnv* currentThreadEnv,
>>> > >> JNIEnv**
>>> > >> >> > > >> >> newThreadEnv).
>>> > >> >> > > >> >> > > > > > > I'm a little bit confused.....Current
>>> thread
>>> > >> >> hasn't been
>>> > >> >> > > >> >> attached yet.
>>> > >> >> > > >> >> > > > > > > So there is no JNIEnv for it yet. How
>>> it can
>>> > >> >> be passed as
>>> > >> >> > > >> >> the first
>>> > >> >> > > >> >> > > > > > > parameter to vm_attach()?
>>> > >> >> > > >> >> > > > > > >
>>> > >> >> > > >> >> > > > > > > > Then you will be always able to get the
>>> > >> >> JavaVM from the
>>> > >> >> > > >> >> JNIEnv.
>>> > >> >> > > >> >> > > > > > > > The only difference is that you are
>>> > >> >> currently doing
>>> > >> >> > > >> >> JNIEnv->JavaVM
>>> > >> >> > > >> >> > > > > > > > conversion in the VMThreadManager,
>>> but why
>>> > >> >> can't you
>>> > >> >> > > >> >> just do this in
>>> > >> >> > > >> >> > > > > > > > vm_attach() without changing the
>>> interface
>>> > >> >> of the TM?
>>> > >> >> > > >> >> > > > > > > > So far JavaVM really looks like an extra
>>> > >> >> knowledge that
>>> > >> >> > > >> >> TM doesn't
>>> > >> >> > > >> >> > > > > > > > have to be aware of.
>>> > >> >> > > >> >> > > > > > > >
>>> > >> >> > > >> >> > > > > > > > > Moreover there is no JNIEnv when main
>>> > >> >> thread attaches
>>> > >> >> > > >> >> to VM. So we
>>> > >> >> > > >> >> > > > > > > > > should either keep it as is or change
>>> > >> >> original design
>>> > >> >> > > >> >> of TM and attach
>>> > >> >> > > >> >> > > > > > > > > thread to VM before attaching it to
>>> TM.
>>> > >> >> In that case
>>> > >> >> > > >> >> we will have
>>> > >> >> > > >> >> > > > > > > > > valid JNIEnv which can be passed to
>>> > >> >> jthread_atatch. We
>>> > >> >> > > >> >> need to think
>>> > >> >> > > >> >> > > > > > > > > over it twice before changing
>>> > >> something....
>>> > >> >> > > >> >> > > > > > > >
>>> > >> >> > > >> >> > > > > > > > Right. For jthread_attach, JNIenv
>>> needs to
>>> > >> >> be changed
>>> > >> >> > > >> >> from being input
>>> > >> >> > > >> >> > > > > > > > parameter to being the output parameter.
>>> > >> >> The way how
>>> > >> >> > > >> >> JNIenv is
>>> > >> >> > > >> >> > > > > > > > obtained by TM should be vm_attach()
>>> > >> event.
>>> > >> >> > > >> >> > > > > > > OK, JNIEnv is output parameter. And it
>>> > >> >> obtained by
>>> > >> >> > > >> >> vm_attach(). This
>>> > >> >> > > >> >> > > > > > > is exactly like I do in the patch. What I
>>> > >> >> don't understand
>>> > >> >> > > >> >> is how
>>> > >> >> > > >> >> > > > > > > jthread_attach knows to which VM the
>>> thread
>>> > >> >> should be
>>> > >> >> > > >> >> attached? Do you
>>> > >> >> > > >> >> > > > > > > suggest calling vm_attach first to create
>>> > >> >> JNIEnv it pass
>>> > >> >> > > >> >> it to
>>> > >> >> > > >> >> > > > > > > jthread_attach?
>>> > >> >> > > >> >> > > > > > >
>>> > >> >> > > >> >> > > > > > > >
>>> > >> >> > > >> >> > > > > > > > >
>>> > >> >> > > >> >> > > > > > > > >
>>> > >> >> > > >> >> > > > > > > > >
>>> > >> >> > > >> >> > > > > > > > > >
>>> > >> >> > > >> >> > > > > > > > > >
>>> > >> >> > > >> >> > > > > > > > > > 4) Original classlib hythread do
>>> > >> not use
>>> > >> >> > > >> >> hythread_library_t in arguments,
>>> > >> >> > > >> >> > > > > > > > > > It uses following code:
>>> > >> >> > > >> >> > > > > > > > > >
>>> > >> >> > > >> >> > > > > > > > > > hythread_library_t lib =
>>> GLOBAL_DATA
>>> > >> >> > > >> >> (default_library);
>>> > >> >> > > >> >> > > > > > > > > > or
>>> > >> >> > > >> >> > > > > > > > > > hythread_library_t library =
>>> thread-
>>> > >> >> >library;
>>> > >> >> > > >> >> > > > > > > > > >
>>> > >> >> > > >> >> > > > > > > > > > So could you please use the same
>>> > >> >> mechanism and
>>> > >> >> > > >> >> remove hythread_*_ex >functions.
>>> > >> >> > > >> >> > > > > > > > > Let's see if classlib's hythread needs
>>> > >> >> changing first.
>>> > >> >> > > >> >> It seems for me
>>> > >> >> > > >> >> > > > > > > > > such code prevents us from having
>>> > >> multi VM.
>>> > >> >> > > >> >> > > > > > > > >
>>> > >> >> > > >> >> > > > > > > > > >
>>> > >> >> > > >> >> > > > > > > > > > 5. You introduce more then one jni
>>> > >> >> env, but still
>>> > >> >> > > >> >> use global variable for it.
>>> > >> >> > > >> >> > > > > > > > > > So all changes like following:
>>> > >> >> > > >> >> > > > > > > > > > - JNIEnv *jenv = (JNIEnv*)
>>> > >> >> jni_native_intf;
>>> > >> >> > > >> >> > > > > > > > > > + JNIEnv *jenv = jni_native_intf;
>>> > >> >> > > >> >> > > > > > > > > >
>>> > >> >> > > >> >> > > > > > > > > > should be like:
>>> > >> >> > > >> >> > > > > > > > > > - JNIEnv *jenv = (JNIEnv*)
>>> > >> >> jni_native_intf;
>>> > >> >> > > >> >> > > > > > > > > > + JNIEnv *jenv = get_jni_env
>>> > >> >> (jthread_self());
>>> > >> >> > > >> >> > > > > > > > >
>>> > >> >> > > >> >> > > > > > > > > Ok, I see. I agree that global
>>> > >> >> jni_native_intf should
>>> > >> >> > > >> >> not be used.
>>> > >> >> > > >> >> > > > > > > > > There was simple reason why I altered
>>> > >> >> such lines.
>>> > >> >> > > >> >> Because I changed
>>> > >> >> > > >> >> > > > > > > > > the type of jni_native_intf and no
>>> > >> >> casting operator
>>> > >> >> > > >> >> is needed now. To
>>> > >> >> > > >> >> > > > > > > > > be honest I think get_jni_env
>>> > >> >> (jthread_self()) can be
>>> > >> >> > > >> >> good as temporary
>>> > >> >> > > >> >> > > > > > > > > solution only. Lets wait for design of
>>> > >> >> multi VM and
>>> > >> >> > > >> >> fix it according
>>> > >> >> > > >> >> > > > > > > > > to it.
>>> > >> >> > > >> >> > > > > > > >
>>> > >> >> > > >> >> > > > > > > > While we are in JNI code, we always have
>>> > >> >> the JNIenv (at
>>> > >> >> > > >> >> least
>>> > >> >> > > >> >> > > > > > > > initially it comes from Java code).
>>> If we
>>> > >> >> consider VM
>>> > >> >> > > >> >> code as if it
>>> > >> >> > > >> >> > > > > > > > was a JNI application, then it seems
>>> like
>>> > >> >> we should be
>>> > >> >> > > >> >> just passing
>>> > >> >> > > >> >> > > > > > > > JNIEnv as a parameter to all
>>> functions in
>>> > >> >> VM. Or, we can
>>> > >> >> > > >> >> be taking it
>>> > >> >> > > >> >> > > > > > > > from TLS (via jthread_self()), depending
>>> > >> >> on which way is
>>> > >> >> > > >> >> faster...
>>> > >> >> > > >> >> > > > > > > Agree.
>>> > >> >> > > >> >> > > > > > >
>>> > >> >> > > >> >> > > > > > > >
>>> > >> >> > > >> >> > > > > > > > >
>>> > >> >> > > >> >> > > > > > > > > >
>>> > >> >> > > >> >> > > > > > > > > > 6). And small remarks:
>>> > >> >> > > >> >> > > > > > > > > > +jint vm_init1(JavaVM_Internal *
>>> > >> java_vm,
>>> > >> >> > > >> >> JavaVMInitArgs * vm_arguments);
>>> > >> >> > > >> >> > > > > > > > > > +jint vm_init2(JNIEnv_Internal *
>>> > >> >> jni_env);
>>> > >> >> > > >> >> > > > > > > > > > Could you make names more
>>> meaningful,
>>> > >> >> then 1,2,3...?
>>> > >> >> > > >> >> > > > > > > > > Ok, will do that.
>>> > >> >> > > >> >> > > > > > > > >
>>> > >> >> > > >> >> > > > > > > > > >
>>> > >> >> > > >> >> > > > > > > > > > class VM_thread {
>>> > >> >> > > >> >> > > > > > > > > > ...
>>> > >> >> > > >> >> > > > > > > > > > + JNIEnv_Internal * jni_env;
>>> > >> >> > > >> >> > > > > > > > > > The jthread already has the jni_env
>>> > >> >> pointer, you do
>>> > >> >> > > >> >> not need to
>>> > >> >> > > >> >> > > > > > > > > > duplicate it here.
>>> > >> >> > > >> >> > > > > > > > > > forexample by using
>>> > >> >> > > >> >> jthread_get_JNI_env(jthread_self());
>>> > >> >> > > >> >> > > > > > > > >
>>> > >> >> > > >> >> > > > > > > > > Yes I know. I don't see any problems
>>> > >> >> here. Some times
>>> > >> >> > > >> >> it is much more
>>> > >> >> > > >> >> > > > > > > > > convenient to get JNIEnv from
>>> VM_thread
>>> > >> >> structure (and
>>> > >> >> > > >> >> faster) instead
>>> > >> >> > > >> >> > > > > > > > > of doing jthread_get_JNI_env
>>> > >> (jthread_self
>>> > >> >> ()). So I
>>> > >> >> > > >> >> need strong
>>> > >> >> > > >> >> > > > > > > > > arguments for removing it. Again it
>>> > >> >> seems that should
>>> > >> >> > > >> >> be addressed in
>>> > >> >> > > >> >> > > > > > > > > design of multi VM. So lets forget
>>> about
>>> > >> >> it for a
>>> > >> >> > > >> >> while...
>>> > >> >> > > >> >> > > > > > > >
>>> > >> >> > > >> >> > > > > > > > I think that the data duplication would
>>> > >> >> always serve as
>>> > >> >> > > >> >> a potential
>>> > >> >> > > >> >> > > > > > > > source of errors - while updating one
>>> copy
>>> > >> >> of object,
>>> > >> >> > > >> >> you may forget
>>> > >> >> > > >> >> > > > > > > > to update the other, often resulting
>>> into
>>> > >> >> a strange
>>> > >> >> > > >> >> behavior of the
>>> > >> >> > > >> >> > > > > > > > whole application. Let's see what are
>>> the
>>> > >> >> specific
>>> > >> >> > > >> >> performance
>>> > >> >> > > >> >> > > > > > > > concerns that have to be addressed.
>>> To get
>>> > >> >> VM_thread
>>> > >> >> > > >> >> structure, you
>>> > >> >> > > >> >> > > > > > > > would eventually go to the TLS, just
>>> like
>>> > >> >> > > >> >> > > > > > > > jthread_get_JNI_env(jthread_self()
>>> > >> would do.
>>> > >> >> > > >> >> > > > > > > If there is already VM_thread structure
>>> for
>>> > >> >> some reasons
>>> > >> >> > > >> >> then there
>>> > >> >> > > >> >> > > > > > > will be no extra access to TLS. It is
>>> > >> >> definitely much
>>> > >> >> > > >> more in
>>> > >> >> > > >> >> > > > > > > jthread_get_JNI_env(jthread_self() than
>>> just
>>> > >> >> one TLS
>>> > >> >> > > >> >> access and one
>>> > >> >> > > >> >> > > > > > > dereferncing. I don't think it is a really
>>> > >> >> big problem
>>> > >> >> > > >> >> now. Do you
>>> > >> >> > > >> >> > > > > > > agree to look at this later. I guess
>>> > >> multi VM
>>> > >> >> > > >> >> implementation will
>>> > >> >> > > >> >> > > > > > > alter it in any case.
>>> > >> >> > > >> >> > > > > > >
>>> > >> >> > > >> >> > > > > > > Thanks
>>> > >> >> > > >> >> > > > > > > Evgueni
>>> > >> >> > > >> >> > > > > > >
>>> > >> >> > > >> >> > > > > > > >
>>> > >> >> > > >> >> > > > > > > > Thanks,
>>> > >> >> > > >> >> > > > > > > > Andrey.
>>> > >> >> > > >> >> > > > > > > >
>>> > >> >> > > >> >> > > > > > > > >
>>> > >> >> > > >> >> > > > > > > > > Evgueni
>>> > >> >> > > >> >> > > > > > > > > >
>>> > >> >> > > >> >> > > > > > > > > > Thanks
>>> > >> >> > > >> >> > > > > > > > > > Artem
>>> > >> >> > > >> >> > > > > > > > > >
>>> > >> >> > > >> >> > > > > > > > > > On 9/28/06, Evgueni Brevnov
>>> > >> >> > > >> >> <ev...@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.
>>> > >> >> > > >> >> > > > > > > > > > >
>>> > >> >> > > >> >> > > > > > > > > > > Thanks
>>> > >> >> > > >> >> > > > > > > > > > > Evgueni
>>> > >> >> > > >> >> > > > > > > > > > >
>>> > >> >> > > >> >> > > > > > > > > > > On 9/28/06, Geir Magnusson Jr.
>>> > >> >> <ge...@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
>>> > >> >> > > >> >> <we...@gmail.com> wrote:
>>> > >> >> > > >> >> > > > > > > > > > > > >> On 9/26/06, Evgueni Brevnov
>>> > >> >> > > >> >> <ev...@gmail.com> wrote:
>>> > >> >> > > >> >> > > > > > > > > > > > >> >
>>> > >> >> > > >> >> > > > > > > > > > > > >> > On 9/27/06, Andrey
>>> Chernyshev
>>> > >> >> > > >> >> <a....@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
>>> > >> >> > > >> >> > > > > > > > > > >
>>> > >> >> > > >> >> > > > > > > > > > >
>>> > >> >> > > >> >> > > > > > > > > >
>>> > >> >> > > >> >> > > > > > > > > >
>>> > >> >> > > >> >>
>>> > >> >>
>>> > >>
>>> ---------------------------------------------------------------------
>>> > >> >> > > >> >> > > > > > > > > > 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
>>> > >> >> > > >> >> > > > > > > > >
>>> > >> >> > > >> >> > > > > > > > >
>>> > >> >> > > >> >> > > > > > > >
>>> > >> >> > > >> >> > > > > > > >
>>> > >> >> > > >> >> > > > > > > > --
>>> > >> >> > > >> >> > > > > > > > Andrey Chernyshev
>>> > >> >> > > >> >> > > > > > > > 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
>>> > >> >> > > >> >> > > > > >
>>> > >> >> > > >> >> > > > > >
>>> > >> >> > > >> >> > > > >
>>> > >> >> > > >> >> > > > >
>>> > >> >> > > >> >> > > > > --
>>> > >> >> > > >> >> > > > > Andrey Chernyshev
>>> > >> >> > > >> >> > > > > 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
>>> > >> >> > > >> >> > > >
>>> > >> >> > > >> >> > > >
>>> > >> >> > > >> >> > >
>>> > >> >> > > >> >> > >
>>> > >> >> > > >> >> > > --
>>> > >> >> > > >> >> > > Andrey Chernyshev
>>> > >> >> > > >> >> > > 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
>>> > >> >> > > >>
>>> > >> >> > > >>
>>> > >> >> > > >
>>> > >> >> > > >
>>> > >> >>
>>> > >>
>>> ---------------------------------------------------------------------
>>> > >> >> > > > 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
>>> > >> >
>>> > >>
>>> > >>
>>> > >>
>>> ---------------------------------------------------------------------
>>> > >> 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
>>> >
>>> >
>>>
>>
>> ---------------------------------------------------------------------
>> 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
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Evgueni Brevnov wrote:
> Geir, Salikh,
>
> cunit tests are very unstable...... that's why we have different
> results on different platforms. It all tests problems. I already fixed
> several places but it seems there is much more left. I believe we need
> to revise them all. The main problem is that sleep(somthing) is used
> to synchronize different threads. Sometimes there is no synchraniztion
> at all. I propouse for switching it off until they get stable.
> Can we do it?
No. They all pass for me now, and I think that they are important as
they are better than nothing.
I suspected that these were just timing issues - we should just hunker
down and get them fixed ASAP. We're making progress
geir
>
> Evgueni
>
> On 10/9/06, Evgueni Brevnov <ev...@gmail.com> wrote:
>> Could you insert sleep_a_click(); just before line 59 right after
>> hysem_create(&start, 0, 1):
>>
>> Does it help?
>>
>> On 10/9/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>> > [echo] ## Executing C unit test: test_ti_instrum
>> > [exec] Result: 1
>> > [echo] INFO: TEST test_jthread_get_all_threads start
>> > [echo] ERROR: Assertion '(thread_count)==(i +
>> > initial_thread_count)' failed at /home/geir/dev/apache/harmony/
>> > enhanced/trunk/working_vm/vm/tes
>> > ts/unit/thread/test_ti_instrum.c:94
>> > [echo] Init1: initial_thread_count=1, initial_all_threads_count=1
>> > [echo] Init3: initial_thread_count=1, initial_all_threads_count=1
>> > [echo] Init3: thread_count=3, all_threads_count=3
>> > [echo] INFO: TEST test_jthread_get_all_threads: FAILED
>> > [echo] INFO: TEST test_jthread_get_thread_count start
>> > [echo] Init1: initial_thread_count=3, initial_all_threads_count=3
>> > [echo] INFO: TEST test_jthread_get_thread_count: PASSED
>> > [echo] INFO: TEST test_jthread_get_blocked_count start
>> > [echo] INFO: TEST test_jthread_get_blocked_count: PASSED
>> > [echo] ## TEST FAILED
>> >
>> >
>> > On Oct 9, 2006, at 12:35 AM, Evgueni Brevnov wrote:
>> >
>> > > I put debug printing into test_ti_instrum.c and attached it to JIRA.
>> > > Could you run it on your machine and send me console output.
>> > >
>> > > Evgueni
>> > >
>> > > On 10/9/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>> > >> I keep getting a failure when running the tests -
>> > >>
>> > >> test_jthread_get_all-threads failling the assertion at
>> > >> test_ti_instrum.c:80
>> > >>
>> > >> geir
>> > >>
>> > >> On Oct 8, 2006, at 7:19 AM, Evgueni Brevnov wrote:
>> > >>
>> > >> > While running cunit on Linux it turned out one test case fails
>> some
>> > >> > time. The fix is in tests.final.2.patch.
>> > >> >
>> > >> > So the last versions to be committed:
>> > >> > invocation_api.final.patch
>> > >> > build.final.2.patch
>> > >> > tests.final.2.patch
>> > >> >
>> > >> > Evgueni
>> > >> >
>> > >> >
>> > >> > On 10/8/06, Evgueni Brevnov <ev...@gmail.com> wrote:
>> > >> >> I mahaged to resolve the problem on Linux.... will update
>> > >> >> build.final.patch with build.final.2.patch in a while
>> > >> >>
>> > >> >> On 10/8/06, Evgueni Brevnov <ev...@gmail.com> wrote:
>> > >> >> > Hi,
>> > >> >> >
>> > >> >> > Oh! Ooh! I did that..... I passed cunit, somke, kernel tests on
>> > >> >> > Windows and smoke, kernel tests on Linux. Unfortunately I
>> > >> failed to
>> > >> >> > link cunit tests on Linux so far. So I disabled cunit on Linux
>> > >> >> until
>> > >> >> > the problem is solved. I believe it is acceptable as short term
>> > >> >> > solution. I found several problems in cunit tests. I will come
>> > >> >> up with
>> > >> >> > my findings later (not today).
>> > >> >> >
>> > >> >> > Use latest patches from HARMONY-1582. They are marked as final.
>> > >> >> There
>> > >> >> > are three patches. One for build module, one for cunit tests
>> and
>> > >> >> one
>> > >> >> > for VM itself.
>> > >> >> >
>> > >> >> > Thanks
>> > >> >> > Evgueni
>> > >> >> >
>> > >> >> >
>> > >> >> > On 10/6/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>> > >> >> > > Nooooooo! LOL
>> > >> >> > >
>> > >> >> > > I'm here waiting - This will unblock a whole bunch of
>> > >> things :)
>> > >> >> > >
>> > >> >> > > Thanks for the effort
>> > >> >> > >
>> > >> >> > > Evgueni Brevnov wrote:
>> > >> >> > > > Geir,
>> > >> >> > > >
>> > >> >> > > > That's terrible. We have power outage....servers are
>> down. I
>> > >> >> can't
>> > >> >> > > > send the patches now.... will do it tomorrow
>> > >> >> > > >
>> > >> >> > > > Evgueni
>> > >> >> > > > On 10/5/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>> > >> >> > > >> woo hoo! here we go...
>> > >> >> > > >>
>> > >> >> > > >>
>> > >> >> > > >> Andrey Chernyshev wrote:
>> > >> >> > > >> > Hi Evgueni,
>> > >> >> > > >> >
>> > >> >> > > >> > On 10/4/06, Evgueni Brevnov <ev...@gmail.com>
>> > >> >> wrote:
>> > >> >> > > >> >> Hi All,
>> > >> >> > > >> >>
>> > >> >> > > >> >> I have attached updated patch to the JIRA. It should
>> > >> >> resolve remain
>> > >> >> > > >> >> concerns. Andrey, could you give a green light now?
>> > >> >> > > >> >
>> > >> >> > > >> > Thanks for updating the patch! I agree it it can be
>> > >> >> committed, at
>> > >> >> > > >> > least signatures look good. 5 revisions seem like more
>> > >> >> than enough :).
>> > >> >> > > >> > Anyways, I think the remaining issues can be resolved
>> > >> >> with additional
>> > >> >> > > >> > patches. Thanks again for the good work and your
>> > >> patience.
>> > >> >> > > >> >
>> > >> >> > > >> > Thanks,
>> > >> >> > > >> > Andrey.
>> > >> >> > > >> >
>> > >> >> > > >> >>
>> > >> >> > > >> >> Thanks
>> > >> >> > > >> >> Evgueni
>> > >> >> > > >> >>
>> > >> >> > > >> >> On 10/4/06, Evgueni Brevnov <ev...@gmail.com>
>> > >> >> wrote:
>> > >> >> > > >> >> > Andrey,
>> > >> >> > > >> >> >
>> > >> >> > > >> >> > I see your points. I think both approaches have
>> > >> >> advantages and
>> > >> >> > > >> >> > disadvantages. I think it is quite hard to say which
>> > >> >> approach is
>> > >> >> > > >> >> > better until we play with one VM only. I still feel
>> > >> >> like introducing
>> > >> >> > > >> >> > one more dependence is better than spreading code
>> > >> >> which deals with
>> > >> >> > > >> >> > attachment among VM and TM. We really get stuck. OK,
>> > >> >> just because I
>> > >> >> > > >> >> > want to move forward I will do required changes to
>> > >> remove
>> > >> >> > > >> >> > vm_create_jthread from TM. I believe that will
>> resolve
>> > >> >> all our
>> > >> >> > > >> >> > disagreements and the patch will be applied soon.
>> > >> >> > > >> >> >
>> > >> >> > > >> >> >
>> > >> >> > > >> >> > Thanks
>> > >> >> > > >> >> > Evgueni.
>> > >> >> > > >> >> >
>> > >> >> > > >> >> > On 10/4/06, Andrey Chernyshev
>> > >> >> <a....@gmail.com> wrote:
>> > >> >> > > >> >> > > On 10/3/06, Evgueni Brevnov
>> > >> >> <ev...@gmail.com> wrote:
>> > >> >> > > >> >> > > > On 10/3/06, Andrey Chernyshev
>> > >> >> <a....@gmail.com> wrote:
>> > >> >> > > >> >> > > > > On 10/2/06, Evgueni Brevnov
>> > >> >> <ev...@gmail.com> wrote:
>> > >> >> > > >> >> > > > > > Andrey,
>> > >> >> > > >> >> > > > > >
>> > >> >> > > >> >> > > > > > Just to be clear.... I agree with you it is
>> > >> more
>> > >> >> > > >> convenient if
>> > >> >> > > >> >> > > > > > jthread_create takes JNIEnv instead of
>> > >> JavaVM. It
>> > >> >> > > >> reflects that
>> > >> >> > > >> >> > > > > > current thread has been attached already. Do
>> > >> >> you think it
>> > >> >> > > >> >> makes sense
>> > >> >> > > >> >> > > > > > to get rid of JNIEnv and use
>> > >> >> jthread_get_JNI_env in that
>> > >> >> > > >> case?
>> > >> >> > > >> >> > > > >
>> > >> >> > > >> >> > > > > The jthread_* layer is designed like if it were
>> > >> >> a regular JNI
>> > >> >> > > >> >> > > > > application which is meant to be called from
>> the
>> > >> >> Java code,
>> > >> >> > > >> hence
>> > >> >> > > >> >> > > > > every function on that layer receives
>> JNIenv. We
>> > >> >> can probably
>> > >> >> > > >> >> get rid
>> > >> >> > > >> >> > > > > of the JNEnv parameter for jthread_* functions,
>> > >> >> assuming that
>> > >> >> > > >> >> TM can
>> > >> >> > > >> >> > > > > always extract JNIenv for the current thread
>> > >> with
>> > >> >> > > >> >> > > > > jthread_get_JNI_env().
>> > >> >> > > >> >> > > > > My only concern would be the performance -
>> once
>> > >> >> the JNIenv is
>> > >> >> > > >> >> already
>> > >> >> > > >> >> > > > > known for the native part of the kernel classes
>> > >> >> impl, it
>> > >> >> > > >> must be
>> > >> >> > > >> >> > > > > cheaper to pass JNIEnv to TM as an extra
>> > >> >> parameter rather than
>> > >> >> > > >> >> extract
>> > >> >> > > >> >> > > > > it from the TLS again.
>> > >> >> > > >> >> > > > > Other than that, I see no strong advantages in
>> > >> >> keeping JNIEnv
>> > >> >> > > >> >> parameter.
>> > >> >> > > >> >> > > > >
>> > >> >> > > >> >> > > > >
>> > >> >> > > >> >> > > > > > Regarding jthread_attach. I still didn't get
>> > >> >> your point....
>> > >> >> > > >> >> Clarify it
>> > >> >> > > >> >> > > > > > please if you think jhread_attach should be
>> > >> >> modified.
>> > >> >> > > >> >> > > > >
>> > >> >> > > >> >> > > > > Sorry for being not clear: I think for
>> > >> >> jthread_attach, we have
>> > >> >> > > >> >> two options:
>> > >> >> > > >> >> > > > > 1) Make JNIEnv input parameter - it must be new
>> > >> >> JNIEnv that VM
>> > >> >> > > >> >> > > > > pre-allocates for the new Java thread.
>> > >> >> jthread_attach
>> > >> >> > > >> would just
>> > >> >> > > >> >> > > > > associate it with the current thread.
>> > >> >> > > >> >> > > > >
>> > >> >> > > >> >> > > > > 2) Obtain JNIEnv via vm_attach() callback. In
>> > >> >> this case, if
>> > >> >> > > >> >> > > > > vm_attach() callback implementation needs to
>> > >> >> know for which
>> > >> >> > > >> >> JavaVM new
>> > >> >> > > >> >> > > > > JNIenv has to be allocated, then we'll need to
>> > >> >> add JavaVM as
>> > >> >> > > >> >> input
>> > >> >> > > >> >> > > > > parameter for jthread_attach().
>> > >> >> > > >> >> > > > > I think both options should be fine, (1) would
>> > >> >> probably
>> > >> >> > > >> keep TM
>> > >> >> > > >> >> > > > > interface a bit lighter, though (2) may look
>> > >> >> more closer to
>> > >> >> > > >> >> the JNI
>> > >> >> > > >> >> > > > > invocation API idea.
>> > >> >> > > >> >> > > > > So I think adding JavaVM specifically for
>> > >> >> jthread_attach
>> > >> >> > > >> may make
>> > >> >> > > >> >> > > > > sense given the explanation you provided
>> > >> earlier.
>> > >> >> > > >> >> > > > >
>> > >> >> > > >> >> > > > > The concern I would have regarding the proposed
>> > >> >> jthread_attach
>> > >> >> > > >> >> > > > > implementation is a call to vm_create_jthread()
>> > >> >> - this call
>> > >> >> > > >> >> introduces
>> > >> >> > > >> >> > > > > an extra dependency of TM on vmcore that I'd
>> > >> >> prefer to be
>> > >> >> > > >> >> avoided. In
>> > >> >> > > >> >> > > > > the original version, jthread_attach() was
>> > >> >> taking jthread
>> > >> >> > > >> >> argument of
>> > >> >> > > >> >> > > > > the already prepared j.l.Thread.
>> > >> >> > > >> >> > > >
>> > >> >> > > >> >> > > > I understand your concern. Unfortunately I don't
>> > >> >> see what we
>> > >> >> > > >> can do
>> > >> >> > > >> >> > > > here. Let me explain. In the beginning you
>> have an
>> > >> >> unattached
>> > >> >> > > >> >> native
>> > >> >> > > >> >> > > > thread. To be able to call java code (which is
>> > >> >> required for
>> > >> >> > > >> >> > > > constructing j.l.Thread instance) the thread
>> > >> >> should be attached
>> > >> >> > > >> >> first.
>> > >> >> > > >> >> > > > To be specific it should be attached to VM by
>> > >> >> calling vm_attach
>> > >> >> > > >> >> which
>> > >> >> > > >> >> > > > will return a valid JNIEnv It is valid to use JNI
>> > >> >> from that
>> > >> >> > > >> moment.
>> > >> >> > > >> >> > > > Obtained JNIEnv can be used to execute java code
>> > >> >> and create
>> > >> >> > > >> >> j.l.Thread
>> > >> >> > > >> >> > > > instance. Since we do vm_attach in jthread_attach
>> > >> >> we need to do
>> > >> >> > > >> >> > > > vm_create_jthread inside jthread_atach as well.
>> > >> >> > > >> >> > > > Of course it can be an alternative to do
>> vm_attach
>> > >> >> and
>> > >> >> > > >> >> > > > vm_create_jthread outside of TM right before
>> > >> >> jthread_attach.
>> > >> >> > > >> >> Sure it
>> > >> >> > > >> >> > > > will reduce one dependence between VM and TM. But
>> > >> >> it seems like
>> > >> >> > > >> >> > > > artificial action for me just because of
>> > >> >> dependency....
>> > >> >> > > >> >> > >
>> > >> >> > > >> >> > > Why do you think it is artificial? I would rather
>> > >> >> prefer not to
>> > >> >> > > >> throw
>> > >> >> > > >> >> > > vm_attach event from the jthread_attach() call at
>> > >> >> all than to add
>> > >> >> > > >> >> > > extra dependency. The idea of jthread layer is a
>> > >> >> Java face to
>> > >> >> > > >> >> > > hythread, it is meant to know either a little or
>> > >> >> nothing about the
>> > >> >> > > >> >> > > rest of VM. It may be logical to throw vm_attach
>> > >> >> call from the
>> > >> >> > > >> newly
>> > >> >> > > >> >> > > created thread, because there is no other way to
>> let
>> > >> >> know VM
>> > >> >> > > >> the new
>> > >> >> > > >> >> > > thread is created. VM attach is a different case -
>> > >> >> VM already
>> > >> >> > > >> knows
>> > >> >> > > >> >> > > about new Java thread at the time of the
>> > >> >> AttachCurrentThread call.
>> > >> >> > > >> >> > >
>> > >> >> > > >> >> > > >
>> > >> >> > > >> >> > > > > Do you think it makes sense to replace a single
>> > >> >> jthread
>> > >> >> > > >> >> parameter with
>> > >> >> > > >> >> > > > > a variety of stuff (like thread group,
>> name)? It
>> > >> >> seems the
>> > >> >> > > >> only
>> > >> >> > > >> >> > > > > purpose of at these args is to be passed
>> back to
>> > >> >> VM for
>> > >> >> > > >> >> > > > > vm_jthread_create(). I would suggest to change
>> > >> >> this and try
>> > >> >> > > >> doing
>> > >> >> > > >> >> > > > > either of:
>> > >> >> > > >> >> > > > > 1) Make signature of jthread_attach with 3
>> args,
>> > >> >> JavaVM,
>> > >> >> > > >> >> jthread and the daemon.
>> > >> >> > > >> >> > > > Why do you want to pass daemon to TM but thread's
>> > >> >> name and
>> > >> >> > > >> >> group. Just
>> > >> >> > > >> >> > > > because current TM doesn't need such information?
>> > >> >> What if it is
>> > >> >> > > >> >> > > > required to get thread name later? Say by
>> > >> introducing
>> > >> >> > > >> >> > >
>> > >> >> > > >> >> > > I imagine you need a daemon attribute since the TM
>> > >> >> is still
>> > >> >> > > >> managing
>> > >> >> > > >> >> > > the thread daemonality. TM is not managing thread
>> > >> >> name and group -
>> > >> >> > > >> >> > > they are all kept on the Java level, hence passing
>> > >> >> them may be
>> > >> >> > > >> >> > > excessive.
>> > >> >> > > >> >> > >
>> > >> >> > > >> >> > > > jthread_get_name... What will you do in that
>> case?
>> > >> >> Let me
>> > >> >> > > >> guess you
>> > >> >> > > >> >> > > > will call j.l.Thread.getName. Right. Ok! In that
>> > >> >> case I see no
>> > >> >> > > >> >> > > > problems to call j.l.Thread.isDaemon. Do you
>> > >> >> agree? So it
>> > >> >> > > >> doesn't
>> > >> >> > > >> >> > >
>> > >> >> > > >> >> > > As I suggested earlier, the best way to handle
>> > >> >> daemonality would
>> > >> >> > > >> >> > > probably be in pure Java - in j.l.Thread (or
>> > >> >> > > >> j.l.VMThreadManager) or
>> > >> >> > > >> >> > > whatever. You already lifted it up to the jthread
>> > >> >> level, but
>> > >> >> > > >> what if
>> > >> >> > > >> >> > > we can go a little bit higher...
>> > >> >> > > >> >> > >
>> > >> >> > > >> >> > > > seems to be a good design to pass only part of
>> the
>> > >> >> > > >> information to
>> > >> >> > > >> >> > > > jthread_atach. Lets look at the signature of
>> > >> >> > > >> >> AttachCurrentThread. It
>> > >> >> > > >> >> > > > takes exactly these three parameters (daemon,
>> > >> >> name, group)
>> > >> >> > > >> >> passed as a
>> > >> >> > > >> >> > > > structure. I was thinking about having exactly
>> the
>> > >> >> same
>> > >> >> > > >> >> structure as
>> > >> >> > > >> >> > > > third parameter of jthread_attach but it occured
>> > >> >> to be more
>> > >> >> > > >> >> convinient
>> > >> >> > > >> >> > > > to pass them seperatly. Although I don't see
>> > >> >> strong reasons
>> > >> >> > > >> against
>> > >> >> > > >> >> > > > having a structure a third parameter.
>> > >> >> > > >> >> > >
>> > >> >> > > >> >> > > I see. Acually, I would love to keep the
>> > >> >> jthread_attach func-ty at
>> > >> >> > > >> >> the
>> > >> >> > > >> >> > > minimum level which will be needed to handle the
>> > >> >> only data that TM
>> > >> >> > > >> >> > > should be aware of. We need a formal boundary
>> > >> >> between jthread
>> > >> >> > > >> layer
>> > >> >> > > >> >> > > and vmcore (otherwise jthread won't have a much of
>> > >> >> sense, one may
>> > >> >> > > >> >> > > consider it just as a convenience set of functions
>> > >> >> in vmcore which
>> > >> >> > > >> >> are
>> > >> >> > > >> >> > > doing something with threading).
>> > >> >> > > >> >> > >
>> > >> >> > > >> >> > > >
>> > >> >> > > >> >> > > > > 2) Move the implementation of vm_create_jtrhead
>> > >> >> () to
>> > >> >> > > >> >> > > > > thread_java_basic.c - could it be written in
>> > >> >> pure JNI without
>> > >> >> > > >> >> using
>> > >> >> > > >> >> > > > > internal VM API like class_alloc_new_object()?
>> > >> >> > > >> >> > > >
>> > >> >> > > >> >> > > > Yes, this can be done but it doesn't fix the
>> > >> >> problem. You still
>> > >> >> > > >> >> need
>> > >> >> > > >> >> > > > to know about internal constructor of j.l.Thread
>> > >> >> > > >> >> > >
>> > >> >> > > >> >> > > That's bad. Given what you said, now it seems that
>> > >> >> the most
>> > >> >> > > >> >> preferable
>> > >> >> > > >> >> > > sequence for AttachCurrentThread impl still
>> would be
>> > >> >> like:
>> > >> >> > > >> >> > > JNIEnv = vm_attach();
>> > >> >> > > >> >> > > jthread = create_jthread(JNIenv)
>> > >> >> > > >> >> > > jthread_attach(JNIEnv, jthread) // stores JNIEnv
>> and
>> > >> >> Hythread into
>> > >> >> > > >> >> > > TLS, doesn't call vm_attach any longer.
>> > >> >> > > >> >> > > - this is almost what we had from the beginning...
>> > >> >> > > >> >> > >
>> > >> >> > > >> >> > > Thanks,
>> > >> >> > > >> >> > > Andrey.
>> > >> >> > > >> >> > >
>> > >> >> > > >> >> > > >
>> > >> >> > > >> >> > > >
>> > >> >> > > >> >> > > > Thanks
>> > >> >> > > >> >> > > > Evgueni
>> > >> >> > > >> >> > > > >
>> > >> >> > > >> >> > > > >
>> > >> >> > > >> >> > > > > Thanks,
>> > >> >> > > >> >> > > > > Andrey.
>> > >> >> > > >> >> > > > >
>> > >> >> > > >> >> > > > > >
>> > >> >> > > >> >> > > > > > Thank you
>> > >> >> > > >> >> > > > > > Evgueni
>> > >> >> > > >> >> > > > > >
>> > >> >> > > >> >> > > > > > On 10/2/06, Evgueni Brevnov
>> > >> >> <ev...@gmail.com>
>> > >> >> > > >> wrote:
>> > >> >> > > >> >> > > > > > > On 9/29/06, Andrey Chernyshev
>> > >> >> <a....@gmail.com>
>> > >> >> > > >> >> wrote:
>> > >> >> > > >> >> > > > > > > > On 9/29/06, Evgueni Brevnov
>> > >> >> <ev...@gmail.com>
>> > >> >> > > >> >> wrote:
>> > >> >> > > >> >> > > > > > > > > Artem,
>> > >> >> > > >> >> > > > > > > > >
>> > >> >> > > >> >> > > > > > > > > Thank you for your feedback.... find my
>> > >> >> inlined.....
>> > >> >> > > >> >> > > > > > > > >
>> > >> >> > > >> >> > > > > > > > > On 9/29/06, Artem Aliev
>> > >> >> <ar...@gmail.com> wrote:
>> > >> >> > > >> >> > > > > > > > > > Evgueni,
>> > >> >> > > >> >> > > > > > > > > >
>> > >> >> > > >> >> > > > > > > > > > I got most of your changes, but still
>> > >> >> disagree
>> > >> >> > > >> with all
>> > >> >> > > >> >> > > > > > > > > > hythread/jthread interface changes.
>> > >> >> Could leave
>> > >> >> > > >> >> interface unchanged.
>> > >> >> > > >> >> > > > > > > > > > See following possible solutions,
>> that
>> > >> >> could solve
>> > >> >> > > >> >> the same problems
>> > >> >> > > >> >> > > > > > > > > > without interface changes.
>> > >> >> > > >> >> > > > > > > > > >
>> > >> >> > > >> >> > > > > > > > > >
>> > >> >> > > >> >> > > > > > > > > > 1) daemon attribute is a java
>> > >> >> specific. (Andrey
>> > >> >> > > >> >> mentioned this already).
>> > >> >> > > >> >> > > > > > > > > > Could you please move it back. to
>> > >> >> the jthread
>> > >> >> > > >> >> layer. It is better
>> > >> >> > > >> >> > > > > > > > > > to rename
>> > >> >> > > >> >> > > > > > > > > >
>> > >> >> hythread_wait_for_all_nondaemon_threads() to
>> > >> >> > > >> >> > > > > > > > > >
>> > >> jthread_wait_for_all_nondaemon_threads().
>> > >> >> > > >> >> > > > > > > > > Ok, I see no problems to move "daemon"
>> > >> >> to java layer.
>> > >> >> > > >> >> In that case:
>> > >> >> > > >> >> > > > > > > > > 1) I will move
>> > >> >> > > >> >> hythread_wait_for_all_nondaemon_threads() from
>> > >> >> > > >> >> > > > > > > > > thread_init.c to one which implements
>> > >> >> java layer.
>> > >> >> > > >> >> > > > > > > > > 2) I will move daemon field from
>> > >> >> HyThread structure.
>> > >> >> > > >> >> > > > > > > > >
>> > >> >> > > >> >> > > > > > > > > Agree?
>> > >> >> > > >> >> > > > > > > >
>> > >> >> > > >> >> > > > > > > > Sounds good to me.
>> > >> >> > > >> >> > > > > > >
>> > >> >> > > >> >> > > > > > > OK, will do that.
>> > >> >> > > >> >> > > > > > >
>> > >> >> > > >> >> > > > > > > >
>> > >> >> > > >> >> > > > > > > >
>> > >> >> > > >> >> > > > > > > > >
>> > >> >> > > >> >> > > > > > > > > >
>> > >> >> > > >> >> > > > > > > > > > 2) JavaVM could be retrieved from
>> > >> >> JNIEnv by
>> > >> >> > > >> >> jni_get_java_vm(). So
>> > >> >> > > >> >> > > > > > > > > > let the jthread_create() and
>> others to
>> > >> >> use JNIEnv
>> > >> >> > > >> >> (that is passed from
>> > >> >> > > >> >> > > > > > > > > > java native method).
>> > >> >> > > >> >> > > > > > > > > > The vm_attach could get old JNI env
>> > >> >> and create new
>> > >> >> > > >> >> one for the new thread.
>> > >> >> > > >> >> > > > > > > > > > The first JNIEnv is created in
>> > >> >> CreateVM call and
>> > >> >> > > >> >> could be passed to
>> > >> >> > > >> >> > > > > > > > > > the first thread at startup.
>> > >> >> > > >> >> > > > > > > > > No, no, no. I completely disagree with
>> > >> >> that!!! Why do
>> > >> >> > > >> >> you like JNIEnv
>> > >> >> > > >> >> > > > > > > > > but JavaVM. Why do you think that
>> > >> >> passing JavaVM
>> > >> >> > > >> >> instead of JNIEnv
>> > >> >> > > >> >> > > > > > > > > makes TM less modular? I don't see any
>> > >> >> difference
>> > >> >> > > >> >> here.... It seems
>> > >> >> > > >> >> > > > > > > > > for me like a big big hack to grab
>> > >> >> JNIEnv from another
>> > >> >> > > >> >> thread and pass
>> > >> >> > > >> >> > > > > > > > > it to jthread_attach to perform
>> > >> >> operations in the
>> > >> >> > > >> >> current thread.
>> > >> >> > > >> >> > > > > > > >
>> > >> >> > > >> >> > > > > > > > TM needs to know JNIEnv, mainly for
>> > >> >> managing the
>> > >> >> > > >> >> references to
>> > >> >> > > >> >> > > > > > > > objects, throwing exceptions and calling
>> > >> >> run() method of
>> > >> >> > > >> >> a new thread.
>> > >> >> > > >> >> > > > > > > > JNI spec proposes that JNIEnv is valid
>> > >> >> within the given
>> > >> >> > > >> >> thread, this
>> > >> >> > > >> >> > > > > > > > is why TM holds the JNIEnv pointer at the
>> > >> >> moment. This
>> > >> >> > > >> >> is why TM likes
>> > >> >> > > >> >> > > > > > > > the JNIEnv.
>> > >> >> > > >> >> > > > > > > >
>> > >> >> > > >> >> > > > > > > > Having the JNIEnv, one is able to get
>> > >> >> JavaVM but not
>> > >> >> > > >> >> vise versa. This
>> > >> >> > > >> >> > > > > > > > is why TM doesn't like the JavaVM :)
>> > >> >> > > >> >> > > > > > > I see your point. Only one note this is
>> true
>> > >> >> for already
>> > >> >> > > >> >> attached threads...
>> > >> >> > > >> >> > > > > > >
>> > >> >> > > >> >> > > > > > > >
>> > >> >> > > >> >> > > > > > > > I agree with you that there is a design
>> > >> >> flaw that the
>> > >> >> > > >> >> JNIEnv is copied
>> > >> >> > > >> >> > > > > > > > from the parent thread to a child thread
>> > >> >> during thread
>> > >> >> > > >> >> creation. I
>> > >> >> > > >> >> > > > > > > > think it could be resolved via
>> vm_attach()
>> > >> >> hook - with
>> > >> >> > > >> >> this event, VM
>> > >> >> > > >> >> > > > > > > > might tell the TM what the JNIEnv pointer
>> > >> >> for new thread
>> > >> >> > > >> >> should be. I
>> > >> >> > > >> >> > > > > > > > think you did that by extending the
>> > >> >> vm_attach() call
>> > >> >> > > >> >> with the JNIEnv**
>> > >> >> > > >> >> > > > > > > > argument.
>> > >> >> > > >> >> > > > > > > >
>> > >> >> > > >> >> > > > > > > > What is not completely clear is, why do
>> > >> >> you have to pass
>> > >> >> > > >> >> the JavaVM
>> > >> >> > > >> >> > > > > > > > forth and back, once from VM to TM, and
>> > >> >> then back from
>> > >> >> > > >> >> TM to VM again?
>> > >> >> > > >> >> > > > > > > >
>> > >> >> > > >> >> > > > > > > > If you need to know in jthread_attach,
>> > >> >> which particular
>> > >> >> > > >> >> VM vm_attach()
>> > >> >> > > >> >> > > > > > > > event is coming from, you could have
>> > >> >> vm_attach like
>> > >> >> > > >> >> > > > > > > > vm_attach(JNIEnv* currentThreadEnv,
>> > >> JNIEnv**
>> > >> >> > > >> >> newThreadEnv).
>> > >> >> > > >> >> > > > > > > I'm a little bit confused.....Current
>> thread
>> > >> >> hasn't been
>> > >> >> > > >> >> attached yet.
>> > >> >> > > >> >> > > > > > > So there is no JNIEnv for it yet. How it
>> can
>> > >> >> be passed as
>> > >> >> > > >> >> the first
>> > >> >> > > >> >> > > > > > > parameter to vm_attach()?
>> > >> >> > > >> >> > > > > > >
>> > >> >> > > >> >> > > > > > > > Then you will be always able to get the
>> > >> >> JavaVM from the
>> > >> >> > > >> >> JNIEnv.
>> > >> >> > > >> >> > > > > > > > The only difference is that you are
>> > >> >> currently doing
>> > >> >> > > >> >> JNIEnv->JavaVM
>> > >> >> > > >> >> > > > > > > > conversion in the VMThreadManager, but
>> why
>> > >> >> can't you
>> > >> >> > > >> >> just do this in
>> > >> >> > > >> >> > > > > > > > vm_attach() without changing the
>> interface
>> > >> >> of the TM?
>> > >> >> > > >> >> > > > > > > > So far JavaVM really looks like an extra
>> > >> >> knowledge that
>> > >> >> > > >> >> TM doesn't
>> > >> >> > > >> >> > > > > > > > have to be aware of.
>> > >> >> > > >> >> > > > > > > >
>> > >> >> > > >> >> > > > > > > > > Moreover there is no JNIEnv when main
>> > >> >> thread attaches
>> > >> >> > > >> >> to VM. So we
>> > >> >> > > >> >> > > > > > > > > should either keep it as is or change
>> > >> >> original design
>> > >> >> > > >> >> of TM and attach
>> > >> >> > > >> >> > > > > > > > > thread to VM before attaching it to TM.
>> > >> >> In that case
>> > >> >> > > >> >> we will have
>> > >> >> > > >> >> > > > > > > > > valid JNIEnv which can be passed to
>> > >> >> jthread_atatch. We
>> > >> >> > > >> >> need to think
>> > >> >> > > >> >> > > > > > > > > over it twice before changing
>> > >> something....
>> > >> >> > > >> >> > > > > > > >
>> > >> >> > > >> >> > > > > > > > Right. For jthread_attach, JNIenv
>> needs to
>> > >> >> be changed
>> > >> >> > > >> >> from being input
>> > >> >> > > >> >> > > > > > > > parameter to being the output parameter.
>> > >> >> The way how
>> > >> >> > > >> >> JNIenv is
>> > >> >> > > >> >> > > > > > > > obtained by TM should be vm_attach()
>> > >> event.
>> > >> >> > > >> >> > > > > > > OK, JNIEnv is output parameter. And it
>> > >> >> obtained by
>> > >> >> > > >> >> vm_attach(). This
>> > >> >> > > >> >> > > > > > > is exactly like I do in the patch. What I
>> > >> >> don't understand
>> > >> >> > > >> >> is how
>> > >> >> > > >> >> > > > > > > jthread_attach knows to which VM the thread
>> > >> >> should be
>> > >> >> > > >> >> attached? Do you
>> > >> >> > > >> >> > > > > > > suggest calling vm_attach first to create
>> > >> >> JNIEnv it pass
>> > >> >> > > >> >> it to
>> > >> >> > > >> >> > > > > > > jthread_attach?
>> > >> >> > > >> >> > > > > > >
>> > >> >> > > >> >> > > > > > > >
>> > >> >> > > >> >> > > > > > > > >
>> > >> >> > > >> >> > > > > > > > >
>> > >> >> > > >> >> > > > > > > > >
>> > >> >> > > >> >> > > > > > > > > >
>> > >> >> > > >> >> > > > > > > > > >
>> > >> >> > > >> >> > > > > > > > > > 4) Original classlib hythread do
>> > >> not use
>> > >> >> > > >> >> hythread_library_t in arguments,
>> > >> >> > > >> >> > > > > > > > > > It uses following code:
>> > >> >> > > >> >> > > > > > > > > >
>> > >> >> > > >> >> > > > > > > > > > hythread_library_t lib = GLOBAL_DATA
>> > >> >> > > >> >> (default_library);
>> > >> >> > > >> >> > > > > > > > > > or
>> > >> >> > > >> >> > > > > > > > > > hythread_library_t library = thread-
>> > >> >> >library;
>> > >> >> > > >> >> > > > > > > > > >
>> > >> >> > > >> >> > > > > > > > > > So could you please use the same
>> > >> >> mechanism and
>> > >> >> > > >> >> remove hythread_*_ex >functions.
>> > >> >> > > >> >> > > > > > > > > Let's see if classlib's hythread needs
>> > >> >> changing first.
>> > >> >> > > >> >> It seems for me
>> > >> >> > > >> >> > > > > > > > > such code prevents us from having
>> > >> multi VM.
>> > >> >> > > >> >> > > > > > > > >
>> > >> >> > > >> >> > > > > > > > > >
>> > >> >> > > >> >> > > > > > > > > > 5. You introduce more then one jni
>> > >> >> env, but still
>> > >> >> > > >> >> use global variable for it.
>> > >> >> > > >> >> > > > > > > > > > So all changes like following:
>> > >> >> > > >> >> > > > > > > > > > - JNIEnv *jenv = (JNIEnv*)
>> > >> >> jni_native_intf;
>> > >> >> > > >> >> > > > > > > > > > + JNIEnv *jenv = jni_native_intf;
>> > >> >> > > >> >> > > > > > > > > >
>> > >> >> > > >> >> > > > > > > > > > should be like:
>> > >> >> > > >> >> > > > > > > > > > - JNIEnv *jenv = (JNIEnv*)
>> > >> >> jni_native_intf;
>> > >> >> > > >> >> > > > > > > > > > + JNIEnv *jenv = get_jni_env
>> > >> >> (jthread_self());
>> > >> >> > > >> >> > > > > > > > >
>> > >> >> > > >> >> > > > > > > > > Ok, I see. I agree that global
>> > >> >> jni_native_intf should
>> > >> >> > > >> >> not be used.
>> > >> >> > > >> >> > > > > > > > > There was simple reason why I altered
>> > >> >> such lines.
>> > >> >> > > >> >> Because I changed
>> > >> >> > > >> >> > > > > > > > > the type of jni_native_intf and no
>> > >> >> casting operator
>> > >> >> > > >> >> is needed now. To
>> > >> >> > > >> >> > > > > > > > > be honest I think get_jni_env
>> > >> >> (jthread_self()) can be
>> > >> >> > > >> >> good as temporary
>> > >> >> > > >> >> > > > > > > > > solution only. Lets wait for design of
>> > >> >> multi VM and
>> > >> >> > > >> >> fix it according
>> > >> >> > > >> >> > > > > > > > > to it.
>> > >> >> > > >> >> > > > > > > >
>> > >> >> > > >> >> > > > > > > > While we are in JNI code, we always have
>> > >> >> the JNIenv (at
>> > >> >> > > >> >> least
>> > >> >> > > >> >> > > > > > > > initially it comes from Java code). If we
>> > >> >> consider VM
>> > >> >> > > >> >> code as if it
>> > >> >> > > >> >> > > > > > > > was a JNI application, then it seems like
>> > >> >> we should be
>> > >> >> > > >> >> just passing
>> > >> >> > > >> >> > > > > > > > JNIEnv as a parameter to all functions in
>> > >> >> VM. Or, we can
>> > >> >> > > >> >> be taking it
>> > >> >> > > >> >> > > > > > > > from TLS (via jthread_self()), depending
>> > >> >> on which way is
>> > >> >> > > >> >> faster...
>> > >> >> > > >> >> > > > > > > Agree.
>> > >> >> > > >> >> > > > > > >
>> > >> >> > > >> >> > > > > > > >
>> > >> >> > > >> >> > > > > > > > >
>> > >> >> > > >> >> > > > > > > > > >
>> > >> >> > > >> >> > > > > > > > > > 6). And small remarks:
>> > >> >> > > >> >> > > > > > > > > > +jint vm_init1(JavaVM_Internal *
>> > >> java_vm,
>> > >> >> > > >> >> JavaVMInitArgs * vm_arguments);
>> > >> >> > > >> >> > > > > > > > > > +jint vm_init2(JNIEnv_Internal *
>> > >> >> jni_env);
>> > >> >> > > >> >> > > > > > > > > > Could you make names more meaningful,
>> > >> >> then 1,2,3...?
>> > >> >> > > >> >> > > > > > > > > Ok, will do that.
>> > >> >> > > >> >> > > > > > > > >
>> > >> >> > > >> >> > > > > > > > > >
>> > >> >> > > >> >> > > > > > > > > > class VM_thread {
>> > >> >> > > >> >> > > > > > > > > > ...
>> > >> >> > > >> >> > > > > > > > > > + JNIEnv_Internal * jni_env;
>> > >> >> > > >> >> > > > > > > > > > The jthread already has the jni_env
>> > >> >> pointer, you do
>> > >> >> > > >> >> not need to
>> > >> >> > > >> >> > > > > > > > > > duplicate it here.
>> > >> >> > > >> >> > > > > > > > > > forexample by using
>> > >> >> > > >> >> jthread_get_JNI_env(jthread_self());
>> > >> >> > > >> >> > > > > > > > >
>> > >> >> > > >> >> > > > > > > > > Yes I know. I don't see any problems
>> > >> >> here. Some times
>> > >> >> > > >> >> it is much more
>> > >> >> > > >> >> > > > > > > > > convenient to get JNIEnv from VM_thread
>> > >> >> structure (and
>> > >> >> > > >> >> faster) instead
>> > >> >> > > >> >> > > > > > > > > of doing jthread_get_JNI_env
>> > >> (jthread_self
>> > >> >> ()). So I
>> > >> >> > > >> >> need strong
>> > >> >> > > >> >> > > > > > > > > arguments for removing it. Again it
>> > >> >> seems that should
>> > >> >> > > >> >> be addressed in
>> > >> >> > > >> >> > > > > > > > > design of multi VM. So lets forget
>> about
>> > >> >> it for a
>> > >> >> > > >> >> while...
>> > >> >> > > >> >> > > > > > > >
>> > >> >> > > >> >> > > > > > > > I think that the data duplication would
>> > >> >> always serve as
>> > >> >> > > >> >> a potential
>> > >> >> > > >> >> > > > > > > > source of errors - while updating one
>> copy
>> > >> >> of object,
>> > >> >> > > >> >> you may forget
>> > >> >> > > >> >> > > > > > > > to update the other, often resulting into
>> > >> >> a strange
>> > >> >> > > >> >> behavior of the
>> > >> >> > > >> >> > > > > > > > whole application. Let's see what are the
>> > >> >> specific
>> > >> >> > > >> >> performance
>> > >> >> > > >> >> > > > > > > > concerns that have to be addressed. To
>> get
>> > >> >> VM_thread
>> > >> >> > > >> >> structure, you
>> > >> >> > > >> >> > > > > > > > would eventually go to the TLS, just like
>> > >> >> > > >> >> > > > > > > > jthread_get_JNI_env(jthread_self()
>> > >> would do.
>> > >> >> > > >> >> > > > > > > If there is already VM_thread structure for
>> > >> >> some reasons
>> > >> >> > > >> >> then there
>> > >> >> > > >> >> > > > > > > will be no extra access to TLS. It is
>> > >> >> definitely much
>> > >> >> > > >> more in
>> > >> >> > > >> >> > > > > > > jthread_get_JNI_env(jthread_self() than
>> just
>> > >> >> one TLS
>> > >> >> > > >> >> access and one
>> > >> >> > > >> >> > > > > > > dereferncing. I don't think it is a really
>> > >> >> big problem
>> > >> >> > > >> >> now. Do you
>> > >> >> > > >> >> > > > > > > agree to look at this later. I guess
>> > >> multi VM
>> > >> >> > > >> >> implementation will
>> > >> >> > > >> >> > > > > > > alter it in any case.
>> > >> >> > > >> >> > > > > > >
>> > >> >> > > >> >> > > > > > > Thanks
>> > >> >> > > >> >> > > > > > > Evgueni
>> > >> >> > > >> >> > > > > > >
>> > >> >> > > >> >> > > > > > > >
>> > >> >> > > >> >> > > > > > > > Thanks,
>> > >> >> > > >> >> > > > > > > > Andrey.
>> > >> >> > > >> >> > > > > > > >
>> > >> >> > > >> >> > > > > > > > >
>> > >> >> > > >> >> > > > > > > > > Evgueni
>> > >> >> > > >> >> > > > > > > > > >
>> > >> >> > > >> >> > > > > > > > > > Thanks
>> > >> >> > > >> >> > > > > > > > > > Artem
>> > >> >> > > >> >> > > > > > > > > >
>> > >> >> > > >> >> > > > > > > > > > On 9/28/06, Evgueni Brevnov
>> > >> >> > > >> >> <ev...@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.
>> > >> >> > > >> >> > > > > > > > > > >
>> > >> >> > > >> >> > > > > > > > > > > Thanks
>> > >> >> > > >> >> > > > > > > > > > > Evgueni
>> > >> >> > > >> >> > > > > > > > > > >
>> > >> >> > > >> >> > > > > > > > > > > On 9/28/06, Geir Magnusson Jr.
>> > >> >> <ge...@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
>> > >> >> > > >> >> <we...@gmail.com> wrote:
>> > >> >> > > >> >> > > > > > > > > > > > >> On 9/26/06, Evgueni Brevnov
>> > >> >> > > >> >> <ev...@gmail.com> wrote:
>> > >> >> > > >> >> > > > > > > > > > > > >> >
>> > >> >> > > >> >> > > > > > > > > > > > >> > On 9/27/06, Andrey
>> Chernyshev
>> > >> >> > > >> >> <a....@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
>> > >> >> > > >> >> > > > > > > > > > >
>> > >> >> > > >> >> > > > > > > > > > >
>> > >> >> > > >> >> > > > > > > > > >
>> > >> >> > > >> >> > > > > > > > > >
>> > >> >> > > >> >>
>> > >> >>
>> > >>
>> ---------------------------------------------------------------------
>> > >> >> > > >> >> > > > > > > > > > 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
>> > >> >> > > >> >> > > > > > > > >
>> > >> >> > > >> >> > > > > > > > >
>> > >> >> > > >> >> > > > > > > >
>> > >> >> > > >> >> > > > > > > >
>> > >> >> > > >> >> > > > > > > > --
>> > >> >> > > >> >> > > > > > > > Andrey Chernyshev
>> > >> >> > > >> >> > > > > > > > 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
>> > >> >> > > >> >> > > > > >
>> > >> >> > > >> >> > > > > >
>> > >> >> > > >> >> > > > >
>> > >> >> > > >> >> > > > >
>> > >> >> > > >> >> > > > > --
>> > >> >> > > >> >> > > > > Andrey Chernyshev
>> > >> >> > > >> >> > > > > 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
>> > >> >> > > >> >> > > >
>> > >> >> > > >> >> > > >
>> > >> >> > > >> >> > >
>> > >> >> > > >> >> > >
>> > >> >> > > >> >> > > --
>> > >> >> > > >> >> > > Andrey Chernyshev
>> > >> >> > > >> >> > > 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
>> > >> >> > > >>
>> > >> >> > > >>
>> > >> >> > > >
>> > >> >> > > >
>> > >> >>
>> > >>
>> ---------------------------------------------------------------------
>> > >> >> > > > 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
>> > >> >
>> > >>
>> > >>
>> > >>
>> ---------------------------------------------------------------------
>> > >> 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
>> >
>> >
>>
>
> ---------------------------------------------------------------------
> 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
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
Posted by Evgueni Brevnov <ev...@gmail.com>.
Geir, Salikh,
cunit tests are very unstable...... that's why we have different
results on different platforms. It all tests problems. I already fixed
several places but it seems there is much more left. I believe we need
to revise them all. The main problem is that sleep(somthing) is used
to synchronize different threads. Sometimes there is no synchraniztion
at all. I propouse for switching it off until they get stable.
Can we do it?
Evgueni
On 10/9/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> Could you insert sleep_a_click(); just before line 59 right after
> hysem_create(&start, 0, 1):
>
> Does it help?
>
> On 10/9/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> > [echo] ## Executing C unit test: test_ti_instrum
> > [exec] Result: 1
> > [echo] INFO: TEST test_jthread_get_all_threads start
> > [echo] ERROR: Assertion '(thread_count)==(i +
> > initial_thread_count)' failed at /home/geir/dev/apache/harmony/
> > enhanced/trunk/working_vm/vm/tes
> > ts/unit/thread/test_ti_instrum.c:94
> > [echo] Init1: initial_thread_count=1, initial_all_threads_count=1
> > [echo] Init3: initial_thread_count=1, initial_all_threads_count=1
> > [echo] Init3: thread_count=3, all_threads_count=3
> > [echo] INFO: TEST test_jthread_get_all_threads: FAILED
> > [echo] INFO: TEST test_jthread_get_thread_count start
> > [echo] Init1: initial_thread_count=3, initial_all_threads_count=3
> > [echo] INFO: TEST test_jthread_get_thread_count: PASSED
> > [echo] INFO: TEST test_jthread_get_blocked_count start
> > [echo] INFO: TEST test_jthread_get_blocked_count: PASSED
> > [echo] ## TEST FAILED
> >
> >
> > On Oct 9, 2006, at 12:35 AM, Evgueni Brevnov wrote:
> >
> > > I put debug printing into test_ti_instrum.c and attached it to JIRA.
> > > Could you run it on your machine and send me console output.
> > >
> > > Evgueni
> > >
> > > On 10/9/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> > >> I keep getting a failure when running the tests -
> > >>
> > >> test_jthread_get_all-threads failling the assertion at
> > >> test_ti_instrum.c:80
> > >>
> > >> geir
> > >>
> > >> On Oct 8, 2006, at 7:19 AM, Evgueni Brevnov wrote:
> > >>
> > >> > While running cunit on Linux it turned out one test case fails some
> > >> > time. The fix is in tests.final.2.patch.
> > >> >
> > >> > So the last versions to be committed:
> > >> > invocation_api.final.patch
> > >> > build.final.2.patch
> > >> > tests.final.2.patch
> > >> >
> > >> > Evgueni
> > >> >
> > >> >
> > >> > On 10/8/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> > >> >> I mahaged to resolve the problem on Linux.... will update
> > >> >> build.final.patch with build.final.2.patch in a while
> > >> >>
> > >> >> On 10/8/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> > >> >> > Hi,
> > >> >> >
> > >> >> > Oh! Ooh! I did that..... I passed cunit, somke, kernel tests on
> > >> >> > Windows and smoke, kernel tests on Linux. Unfortunately I
> > >> failed to
> > >> >> > link cunit tests on Linux so far. So I disabled cunit on Linux
> > >> >> until
> > >> >> > the problem is solved. I believe it is acceptable as short term
> > >> >> > solution. I found several problems in cunit tests. I will come
> > >> >> up with
> > >> >> > my findings later (not today).
> > >> >> >
> > >> >> > Use latest patches from HARMONY-1582. They are marked as final.
> > >> >> There
> > >> >> > are three patches. One for build module, one for cunit tests and
> > >> >> one
> > >> >> > for VM itself.
> > >> >> >
> > >> >> > Thanks
> > >> >> > Evgueni
> > >> >> >
> > >> >> >
> > >> >> > On 10/6/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> > >> >> > > Nooooooo! LOL
> > >> >> > >
> > >> >> > > I'm here waiting - This will unblock a whole bunch of
> > >> things :)
> > >> >> > >
> > >> >> > > Thanks for the effort
> > >> >> > >
> > >> >> > > Evgueni Brevnov wrote:
> > >> >> > > > Geir,
> > >> >> > > >
> > >> >> > > > That's terrible. We have power outage....servers are down. I
> > >> >> can't
> > >> >> > > > send the patches now.... will do it tomorrow
> > >> >> > > >
> > >> >> > > > Evgueni
> > >> >> > > > On 10/5/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> > >> >> > > >> woo hoo! here we go...
> > >> >> > > >>
> > >> >> > > >>
> > >> >> > > >> Andrey Chernyshev wrote:
> > >> >> > > >> > Hi Evgueni,
> > >> >> > > >> >
> > >> >> > > >> > On 10/4/06, Evgueni Brevnov <ev...@gmail.com>
> > >> >> wrote:
> > >> >> > > >> >> Hi All,
> > >> >> > > >> >>
> > >> >> > > >> >> I have attached updated patch to the JIRA. It should
> > >> >> resolve remain
> > >> >> > > >> >> concerns. Andrey, could you give a green light now?
> > >> >> > > >> >
> > >> >> > > >> > Thanks for updating the patch! I agree it it can be
> > >> >> committed, at
> > >> >> > > >> > least signatures look good. 5 revisions seem like more
> > >> >> than enough :).
> > >> >> > > >> > Anyways, I think the remaining issues can be resolved
> > >> >> with additional
> > >> >> > > >> > patches. Thanks again for the good work and your
> > >> patience.
> > >> >> > > >> >
> > >> >> > > >> > Thanks,
> > >> >> > > >> > Andrey.
> > >> >> > > >> >
> > >> >> > > >> >>
> > >> >> > > >> >> Thanks
> > >> >> > > >> >> Evgueni
> > >> >> > > >> >>
> > >> >> > > >> >> On 10/4/06, Evgueni Brevnov <ev...@gmail.com>
> > >> >> wrote:
> > >> >> > > >> >> > Andrey,
> > >> >> > > >> >> >
> > >> >> > > >> >> > I see your points. I think both approaches have
> > >> >> advantages and
> > >> >> > > >> >> > disadvantages. I think it is quite hard to say which
> > >> >> approach is
> > >> >> > > >> >> > better until we play with one VM only. I still feel
> > >> >> like introducing
> > >> >> > > >> >> > one more dependence is better than spreading code
> > >> >> which deals with
> > >> >> > > >> >> > attachment among VM and TM. We really get stuck. OK,
> > >> >> just because I
> > >> >> > > >> >> > want to move forward I will do required changes to
> > >> remove
> > >> >> > > >> >> > vm_create_jthread from TM. I believe that will resolve
> > >> >> all our
> > >> >> > > >> >> > disagreements and the patch will be applied soon.
> > >> >> > > >> >> >
> > >> >> > > >> >> >
> > >> >> > > >> >> > Thanks
> > >> >> > > >> >> > Evgueni.
> > >> >> > > >> >> >
> > >> >> > > >> >> > On 10/4/06, Andrey Chernyshev
> > >> >> <a....@gmail.com> wrote:
> > >> >> > > >> >> > > On 10/3/06, Evgueni Brevnov
> > >> >> <ev...@gmail.com> wrote:
> > >> >> > > >> >> > > > On 10/3/06, Andrey Chernyshev
> > >> >> <a....@gmail.com> wrote:
> > >> >> > > >> >> > > > > On 10/2/06, Evgueni Brevnov
> > >> >> <ev...@gmail.com> wrote:
> > >> >> > > >> >> > > > > > Andrey,
> > >> >> > > >> >> > > > > >
> > >> >> > > >> >> > > > > > Just to be clear.... I agree with you it is
> > >> more
> > >> >> > > >> convenient if
> > >> >> > > >> >> > > > > > jthread_create takes JNIEnv instead of
> > >> JavaVM. It
> > >> >> > > >> reflects that
> > >> >> > > >> >> > > > > > current thread has been attached already. Do
> > >> >> you think it
> > >> >> > > >> >> makes sense
> > >> >> > > >> >> > > > > > to get rid of JNIEnv and use
> > >> >> jthread_get_JNI_env in that
> > >> >> > > >> case?
> > >> >> > > >> >> > > > >
> > >> >> > > >> >> > > > > The jthread_* layer is designed like if it were
> > >> >> a regular JNI
> > >> >> > > >> >> > > > > application which is meant to be called from the
> > >> >> Java code,
> > >> >> > > >> hence
> > >> >> > > >> >> > > > > every function on that layer receives JNIenv. We
> > >> >> can probably
> > >> >> > > >> >> get rid
> > >> >> > > >> >> > > > > of the JNEnv parameter for jthread_* functions,
> > >> >> assuming that
> > >> >> > > >> >> TM can
> > >> >> > > >> >> > > > > always extract JNIenv for the current thread
> > >> with
> > >> >> > > >> >> > > > > jthread_get_JNI_env().
> > >> >> > > >> >> > > > > My only concern would be the performance - once
> > >> >> the JNIenv is
> > >> >> > > >> >> already
> > >> >> > > >> >> > > > > known for the native part of the kernel classes
> > >> >> impl, it
> > >> >> > > >> must be
> > >> >> > > >> >> > > > > cheaper to pass JNIEnv to TM as an extra
> > >> >> parameter rather than
> > >> >> > > >> >> extract
> > >> >> > > >> >> > > > > it from the TLS again.
> > >> >> > > >> >> > > > > Other than that, I see no strong advantages in
> > >> >> keeping JNIEnv
> > >> >> > > >> >> parameter.
> > >> >> > > >> >> > > > >
> > >> >> > > >> >> > > > >
> > >> >> > > >> >> > > > > > Regarding jthread_attach. I still didn't get
> > >> >> your point....
> > >> >> > > >> >> Clarify it
> > >> >> > > >> >> > > > > > please if you think jhread_attach should be
> > >> >> modified.
> > >> >> > > >> >> > > > >
> > >> >> > > >> >> > > > > Sorry for being not clear: I think for
> > >> >> jthread_attach, we have
> > >> >> > > >> >> two options:
> > >> >> > > >> >> > > > > 1) Make JNIEnv input parameter - it must be new
> > >> >> JNIEnv that VM
> > >> >> > > >> >> > > > > pre-allocates for the new Java thread.
> > >> >> jthread_attach
> > >> >> > > >> would just
> > >> >> > > >> >> > > > > associate it with the current thread.
> > >> >> > > >> >> > > > >
> > >> >> > > >> >> > > > > 2) Obtain JNIEnv via vm_attach() callback. In
> > >> >> this case, if
> > >> >> > > >> >> > > > > vm_attach() callback implementation needs to
> > >> >> know for which
> > >> >> > > >> >> JavaVM new
> > >> >> > > >> >> > > > > JNIenv has to be allocated, then we'll need to
> > >> >> add JavaVM as
> > >> >> > > >> >> input
> > >> >> > > >> >> > > > > parameter for jthread_attach().
> > >> >> > > >> >> > > > > I think both options should be fine, (1) would
> > >> >> probably
> > >> >> > > >> keep TM
> > >> >> > > >> >> > > > > interface a bit lighter, though (2) may look
> > >> >> more closer to
> > >> >> > > >> >> the JNI
> > >> >> > > >> >> > > > > invocation API idea.
> > >> >> > > >> >> > > > > So I think adding JavaVM specifically for
> > >> >> jthread_attach
> > >> >> > > >> may make
> > >> >> > > >> >> > > > > sense given the explanation you provided
> > >> earlier.
> > >> >> > > >> >> > > > >
> > >> >> > > >> >> > > > > The concern I would have regarding the proposed
> > >> >> jthread_attach
> > >> >> > > >> >> > > > > implementation is a call to vm_create_jthread()
> > >> >> - this call
> > >> >> > > >> >> introduces
> > >> >> > > >> >> > > > > an extra dependency of TM on vmcore that I'd
> > >> >> prefer to be
> > >> >> > > >> >> avoided. In
> > >> >> > > >> >> > > > > the original version, jthread_attach() was
> > >> >> taking jthread
> > >> >> > > >> >> argument of
> > >> >> > > >> >> > > > > the already prepared j.l.Thread.
> > >> >> > > >> >> > > >
> > >> >> > > >> >> > > > I understand your concern. Unfortunately I don't
> > >> >> see what we
> > >> >> > > >> can do
> > >> >> > > >> >> > > > here. Let me explain. In the beginning you have an
> > >> >> unattached
> > >> >> > > >> >> native
> > >> >> > > >> >> > > > thread. To be able to call java code (which is
> > >> >> required for
> > >> >> > > >> >> > > > constructing j.l.Thread instance) the thread
> > >> >> should be attached
> > >> >> > > >> >> first.
> > >> >> > > >> >> > > > To be specific it should be attached to VM by
> > >> >> calling vm_attach
> > >> >> > > >> >> which
> > >> >> > > >> >> > > > will return a valid JNIEnv It is valid to use JNI
> > >> >> from that
> > >> >> > > >> moment.
> > >> >> > > >> >> > > > Obtained JNIEnv can be used to execute java code
> > >> >> and create
> > >> >> > > >> >> j.l.Thread
> > >> >> > > >> >> > > > instance. Since we do vm_attach in jthread_attach
> > >> >> we need to do
> > >> >> > > >> >> > > > vm_create_jthread inside jthread_atach as well.
> > >> >> > > >> >> > > > Of course it can be an alternative to do vm_attach
> > >> >> and
> > >> >> > > >> >> > > > vm_create_jthread outside of TM right before
> > >> >> jthread_attach.
> > >> >> > > >> >> Sure it
> > >> >> > > >> >> > > > will reduce one dependence between VM and TM. But
> > >> >> it seems like
> > >> >> > > >> >> > > > artificial action for me just because of
> > >> >> dependency....
> > >> >> > > >> >> > >
> > >> >> > > >> >> > > Why do you think it is artificial? I would rather
> > >> >> prefer not to
> > >> >> > > >> throw
> > >> >> > > >> >> > > vm_attach event from the jthread_attach() call at
> > >> >> all than to add
> > >> >> > > >> >> > > extra dependency. The idea of jthread layer is a
> > >> >> Java face to
> > >> >> > > >> >> > > hythread, it is meant to know either a little or
> > >> >> nothing about the
> > >> >> > > >> >> > > rest of VM. It may be logical to throw vm_attach
> > >> >> call from the
> > >> >> > > >> newly
> > >> >> > > >> >> > > created thread, because there is no other way to let
> > >> >> know VM
> > >> >> > > >> the new
> > >> >> > > >> >> > > thread is created. VM attach is a different case -
> > >> >> VM already
> > >> >> > > >> knows
> > >> >> > > >> >> > > about new Java thread at the time of the
> > >> >> AttachCurrentThread call.
> > >> >> > > >> >> > >
> > >> >> > > >> >> > > >
> > >> >> > > >> >> > > > > Do you think it makes sense to replace a single
> > >> >> jthread
> > >> >> > > >> >> parameter with
> > >> >> > > >> >> > > > > a variety of stuff (like thread group, name)? It
> > >> >> seems the
> > >> >> > > >> only
> > >> >> > > >> >> > > > > purpose of at these args is to be passed back to
> > >> >> VM for
> > >> >> > > >> >> > > > > vm_jthread_create(). I would suggest to change
> > >> >> this and try
> > >> >> > > >> doing
> > >> >> > > >> >> > > > > either of:
> > >> >> > > >> >> > > > > 1) Make signature of jthread_attach with 3 args,
> > >> >> JavaVM,
> > >> >> > > >> >> jthread and the daemon.
> > >> >> > > >> >> > > > Why do you want to pass daemon to TM but thread's
> > >> >> name and
> > >> >> > > >> >> group. Just
> > >> >> > > >> >> > > > because current TM doesn't need such information?
> > >> >> What if it is
> > >> >> > > >> >> > > > required to get thread name later? Say by
> > >> introducing
> > >> >> > > >> >> > >
> > >> >> > > >> >> > > I imagine you need a daemon attribute since the TM
> > >> >> is still
> > >> >> > > >> managing
> > >> >> > > >> >> > > the thread daemonality. TM is not managing thread
> > >> >> name and group -
> > >> >> > > >> >> > > they are all kept on the Java level, hence passing
> > >> >> them may be
> > >> >> > > >> >> > > excessive.
> > >> >> > > >> >> > >
> > >> >> > > >> >> > > > jthread_get_name... What will you do in that case?
> > >> >> Let me
> > >> >> > > >> guess you
> > >> >> > > >> >> > > > will call j.l.Thread.getName. Right. Ok! In that
> > >> >> case I see no
> > >> >> > > >> >> > > > problems to call j.l.Thread.isDaemon. Do you
> > >> >> agree? So it
> > >> >> > > >> doesn't
> > >> >> > > >> >> > >
> > >> >> > > >> >> > > As I suggested earlier, the best way to handle
> > >> >> daemonality would
> > >> >> > > >> >> > > probably be in pure Java - in j.l.Thread (or
> > >> >> > > >> j.l.VMThreadManager) or
> > >> >> > > >> >> > > whatever. You already lifted it up to the jthread
> > >> >> level, but
> > >> >> > > >> what if
> > >> >> > > >> >> > > we can go a little bit higher...
> > >> >> > > >> >> > >
> > >> >> > > >> >> > > > seems to be a good design to pass only part of the
> > >> >> > > >> information to
> > >> >> > > >> >> > > > jthread_atach. Lets look at the signature of
> > >> >> > > >> >> AttachCurrentThread. It
> > >> >> > > >> >> > > > takes exactly these three parameters (daemon,
> > >> >> name, group)
> > >> >> > > >> >> passed as a
> > >> >> > > >> >> > > > structure. I was thinking about having exactly the
> > >> >> same
> > >> >> > > >> >> structure as
> > >> >> > > >> >> > > > third parameter of jthread_attach but it occured
> > >> >> to be more
> > >> >> > > >> >> convinient
> > >> >> > > >> >> > > > to pass them seperatly. Although I don't see
> > >> >> strong reasons
> > >> >> > > >> against
> > >> >> > > >> >> > > > having a structure a third parameter.
> > >> >> > > >> >> > >
> > >> >> > > >> >> > > I see. Acually, I would love to keep the
> > >> >> jthread_attach func-ty at
> > >> >> > > >> >> the
> > >> >> > > >> >> > > minimum level which will be needed to handle the
> > >> >> only data that TM
> > >> >> > > >> >> > > should be aware of. We need a formal boundary
> > >> >> between jthread
> > >> >> > > >> layer
> > >> >> > > >> >> > > and vmcore (otherwise jthread won't have a much of
> > >> >> sense, one may
> > >> >> > > >> >> > > consider it just as a convenience set of functions
> > >> >> in vmcore which
> > >> >> > > >> >> are
> > >> >> > > >> >> > > doing something with threading).
> > >> >> > > >> >> > >
> > >> >> > > >> >> > > >
> > >> >> > > >> >> > > > > 2) Move the implementation of vm_create_jtrhead
> > >> >> () to
> > >> >> > > >> >> > > > > thread_java_basic.c - could it be written in
> > >> >> pure JNI without
> > >> >> > > >> >> using
> > >> >> > > >> >> > > > > internal VM API like class_alloc_new_object()?
> > >> >> > > >> >> > > >
> > >> >> > > >> >> > > > Yes, this can be done but it doesn't fix the
> > >> >> problem. You still
> > >> >> > > >> >> need
> > >> >> > > >> >> > > > to know about internal constructor of j.l.Thread
> > >> >> > > >> >> > >
> > >> >> > > >> >> > > That's bad. Given what you said, now it seems that
> > >> >> the most
> > >> >> > > >> >> preferable
> > >> >> > > >> >> > > sequence for AttachCurrentThread impl still would be
> > >> >> like:
> > >> >> > > >> >> > > JNIEnv = vm_attach();
> > >> >> > > >> >> > > jthread = create_jthread(JNIenv)
> > >> >> > > >> >> > > jthread_attach(JNIEnv, jthread) // stores JNIEnv and
> > >> >> Hythread into
> > >> >> > > >> >> > > TLS, doesn't call vm_attach any longer.
> > >> >> > > >> >> > > - this is almost what we had from the beginning...
> > >> >> > > >> >> > >
> > >> >> > > >> >> > > Thanks,
> > >> >> > > >> >> > > Andrey.
> > >> >> > > >> >> > >
> > >> >> > > >> >> > > >
> > >> >> > > >> >> > > >
> > >> >> > > >> >> > > > Thanks
> > >> >> > > >> >> > > > Evgueni
> > >> >> > > >> >> > > > >
> > >> >> > > >> >> > > > >
> > >> >> > > >> >> > > > > Thanks,
> > >> >> > > >> >> > > > > Andrey.
> > >> >> > > >> >> > > > >
> > >> >> > > >> >> > > > > >
> > >> >> > > >> >> > > > > > Thank you
> > >> >> > > >> >> > > > > > Evgueni
> > >> >> > > >> >> > > > > >
> > >> >> > > >> >> > > > > > On 10/2/06, Evgueni Brevnov
> > >> >> <ev...@gmail.com>
> > >> >> > > >> wrote:
> > >> >> > > >> >> > > > > > > On 9/29/06, Andrey Chernyshev
> > >> >> <a....@gmail.com>
> > >> >> > > >> >> wrote:
> > >> >> > > >> >> > > > > > > > On 9/29/06, Evgueni Brevnov
> > >> >> <ev...@gmail.com>
> > >> >> > > >> >> wrote:
> > >> >> > > >> >> > > > > > > > > Artem,
> > >> >> > > >> >> > > > > > > > >
> > >> >> > > >> >> > > > > > > > > Thank you for your feedback.... find my
> > >> >> inlined.....
> > >> >> > > >> >> > > > > > > > >
> > >> >> > > >> >> > > > > > > > > On 9/29/06, Artem Aliev
> > >> >> <ar...@gmail.com> wrote:
> > >> >> > > >> >> > > > > > > > > > Evgueni,
> > >> >> > > >> >> > > > > > > > > >
> > >> >> > > >> >> > > > > > > > > > I got most of your changes, but still
> > >> >> disagree
> > >> >> > > >> with all
> > >> >> > > >> >> > > > > > > > > > hythread/jthread interface changes.
> > >> >> Could leave
> > >> >> > > >> >> interface unchanged.
> > >> >> > > >> >> > > > > > > > > > See following possible solutions, that
> > >> >> could solve
> > >> >> > > >> >> the same problems
> > >> >> > > >> >> > > > > > > > > > without interface changes.
> > >> >> > > >> >> > > > > > > > > >
> > >> >> > > >> >> > > > > > > > > >
> > >> >> > > >> >> > > > > > > > > > 1) daemon attribute is a java
> > >> >> specific. (Andrey
> > >> >> > > >> >> mentioned this already).
> > >> >> > > >> >> > > > > > > > > > Could you please move it back. to
> > >> >> the jthread
> > >> >> > > >> >> layer. It is better
> > >> >> > > >> >> > > > > > > > > > to rename
> > >> >> > > >> >> > > > > > > > > >
> > >> >> hythread_wait_for_all_nondaemon_threads() to
> > >> >> > > >> >> > > > > > > > > >
> > >> jthread_wait_for_all_nondaemon_threads().
> > >> >> > > >> >> > > > > > > > > Ok, I see no problems to move "daemon"
> > >> >> to java layer.
> > >> >> > > >> >> In that case:
> > >> >> > > >> >> > > > > > > > > 1) I will move
> > >> >> > > >> >> hythread_wait_for_all_nondaemon_threads() from
> > >> >> > > >> >> > > > > > > > > thread_init.c to one which implements
> > >> >> java layer.
> > >> >> > > >> >> > > > > > > > > 2) I will move daemon field from
> > >> >> HyThread structure.
> > >> >> > > >> >> > > > > > > > >
> > >> >> > > >> >> > > > > > > > > Agree?
> > >> >> > > >> >> > > > > > > >
> > >> >> > > >> >> > > > > > > > Sounds good to me.
> > >> >> > > >> >> > > > > > >
> > >> >> > > >> >> > > > > > > OK, will do that.
> > >> >> > > >> >> > > > > > >
> > >> >> > > >> >> > > > > > > >
> > >> >> > > >> >> > > > > > > >
> > >> >> > > >> >> > > > > > > > >
> > >> >> > > >> >> > > > > > > > > >
> > >> >> > > >> >> > > > > > > > > > 2) JavaVM could be retrieved from
> > >> >> JNIEnv by
> > >> >> > > >> >> jni_get_java_vm(). So
> > >> >> > > >> >> > > > > > > > > > let the jthread_create() and others to
> > >> >> use JNIEnv
> > >> >> > > >> >> (that is passed from
> > >> >> > > >> >> > > > > > > > > > java native method).
> > >> >> > > >> >> > > > > > > > > > The vm_attach could get old JNI env
> > >> >> and create new
> > >> >> > > >> >> one for the new thread.
> > >> >> > > >> >> > > > > > > > > > The first JNIEnv is created in
> > >> >> CreateVM call and
> > >> >> > > >> >> could be passed to
> > >> >> > > >> >> > > > > > > > > > the first thread at startup.
> > >> >> > > >> >> > > > > > > > > No, no, no. I completely disagree with
> > >> >> that!!! Why do
> > >> >> > > >> >> you like JNIEnv
> > >> >> > > >> >> > > > > > > > > but JavaVM. Why do you think that
> > >> >> passing JavaVM
> > >> >> > > >> >> instead of JNIEnv
> > >> >> > > >> >> > > > > > > > > makes TM less modular? I don't see any
> > >> >> difference
> > >> >> > > >> >> here.... It seems
> > >> >> > > >> >> > > > > > > > > for me like a big big hack to grab
> > >> >> JNIEnv from another
> > >> >> > > >> >> thread and pass
> > >> >> > > >> >> > > > > > > > > it to jthread_attach to perform
> > >> >> operations in the
> > >> >> > > >> >> current thread.
> > >> >> > > >> >> > > > > > > >
> > >> >> > > >> >> > > > > > > > TM needs to know JNIEnv, mainly for
> > >> >> managing the
> > >> >> > > >> >> references to
> > >> >> > > >> >> > > > > > > > objects, throwing exceptions and calling
> > >> >> run() method of
> > >> >> > > >> >> a new thread.
> > >> >> > > >> >> > > > > > > > JNI spec proposes that JNIEnv is valid
> > >> >> within the given
> > >> >> > > >> >> thread, this
> > >> >> > > >> >> > > > > > > > is why TM holds the JNIEnv pointer at the
> > >> >> moment. This
> > >> >> > > >> >> is why TM likes
> > >> >> > > >> >> > > > > > > > the JNIEnv.
> > >> >> > > >> >> > > > > > > >
> > >> >> > > >> >> > > > > > > > Having the JNIEnv, one is able to get
> > >> >> JavaVM but not
> > >> >> > > >> >> vise versa. This
> > >> >> > > >> >> > > > > > > > is why TM doesn't like the JavaVM :)
> > >> >> > > >> >> > > > > > > I see your point. Only one note this is true
> > >> >> for already
> > >> >> > > >> >> attached threads...
> > >> >> > > >> >> > > > > > >
> > >> >> > > >> >> > > > > > > >
> > >> >> > > >> >> > > > > > > > I agree with you that there is a design
> > >> >> flaw that the
> > >> >> > > >> >> JNIEnv is copied
> > >> >> > > >> >> > > > > > > > from the parent thread to a child thread
> > >> >> during thread
> > >> >> > > >> >> creation. I
> > >> >> > > >> >> > > > > > > > think it could be resolved via vm_attach()
> > >> >> hook - with
> > >> >> > > >> >> this event, VM
> > >> >> > > >> >> > > > > > > > might tell the TM what the JNIEnv pointer
> > >> >> for new thread
> > >> >> > > >> >> should be. I
> > >> >> > > >> >> > > > > > > > think you did that by extending the
> > >> >> vm_attach() call
> > >> >> > > >> >> with the JNIEnv**
> > >> >> > > >> >> > > > > > > > argument.
> > >> >> > > >> >> > > > > > > >
> > >> >> > > >> >> > > > > > > > What is not completely clear is, why do
> > >> >> you have to pass
> > >> >> > > >> >> the JavaVM
> > >> >> > > >> >> > > > > > > > forth and back, once from VM to TM, and
> > >> >> then back from
> > >> >> > > >> >> TM to VM again?
> > >> >> > > >> >> > > > > > > >
> > >> >> > > >> >> > > > > > > > If you need to know in jthread_attach,
> > >> >> which particular
> > >> >> > > >> >> VM vm_attach()
> > >> >> > > >> >> > > > > > > > event is coming from, you could have
> > >> >> vm_attach like
> > >> >> > > >> >> > > > > > > > vm_attach(JNIEnv* currentThreadEnv,
> > >> JNIEnv**
> > >> >> > > >> >> newThreadEnv).
> > >> >> > > >> >> > > > > > > I'm a little bit confused.....Current thread
> > >> >> hasn't been
> > >> >> > > >> >> attached yet.
> > >> >> > > >> >> > > > > > > So there is no JNIEnv for it yet. How it can
> > >> >> be passed as
> > >> >> > > >> >> the first
> > >> >> > > >> >> > > > > > > parameter to vm_attach()?
> > >> >> > > >> >> > > > > > >
> > >> >> > > >> >> > > > > > > > Then you will be always able to get the
> > >> >> JavaVM from the
> > >> >> > > >> >> JNIEnv.
> > >> >> > > >> >> > > > > > > > The only difference is that you are
> > >> >> currently doing
> > >> >> > > >> >> JNIEnv->JavaVM
> > >> >> > > >> >> > > > > > > > conversion in the VMThreadManager, but why
> > >> >> can't you
> > >> >> > > >> >> just do this in
> > >> >> > > >> >> > > > > > > > vm_attach() without changing the interface
> > >> >> of the TM?
> > >> >> > > >> >> > > > > > > > So far JavaVM really looks like an extra
> > >> >> knowledge that
> > >> >> > > >> >> TM doesn't
> > >> >> > > >> >> > > > > > > > have to be aware of.
> > >> >> > > >> >> > > > > > > >
> > >> >> > > >> >> > > > > > > > > Moreover there is no JNIEnv when main
> > >> >> thread attaches
> > >> >> > > >> >> to VM. So we
> > >> >> > > >> >> > > > > > > > > should either keep it as is or change
> > >> >> original design
> > >> >> > > >> >> of TM and attach
> > >> >> > > >> >> > > > > > > > > thread to VM before attaching it to TM.
> > >> >> In that case
> > >> >> > > >> >> we will have
> > >> >> > > >> >> > > > > > > > > valid JNIEnv which can be passed to
> > >> >> jthread_atatch. We
> > >> >> > > >> >> need to think
> > >> >> > > >> >> > > > > > > > > over it twice before changing
> > >> something....
> > >> >> > > >> >> > > > > > > >
> > >> >> > > >> >> > > > > > > > Right. For jthread_attach, JNIenv needs to
> > >> >> be changed
> > >> >> > > >> >> from being input
> > >> >> > > >> >> > > > > > > > parameter to being the output parameter.
> > >> >> The way how
> > >> >> > > >> >> JNIenv is
> > >> >> > > >> >> > > > > > > > obtained by TM should be vm_attach()
> > >> event.
> > >> >> > > >> >> > > > > > > OK, JNIEnv is output parameter. And it
> > >> >> obtained by
> > >> >> > > >> >> vm_attach(). This
> > >> >> > > >> >> > > > > > > is exactly like I do in the patch. What I
> > >> >> don't understand
> > >> >> > > >> >> is how
> > >> >> > > >> >> > > > > > > jthread_attach knows to which VM the thread
> > >> >> should be
> > >> >> > > >> >> attached? Do you
> > >> >> > > >> >> > > > > > > suggest calling vm_attach first to create
> > >> >> JNIEnv it pass
> > >> >> > > >> >> it to
> > >> >> > > >> >> > > > > > > jthread_attach?
> > >> >> > > >> >> > > > > > >
> > >> >> > > >> >> > > > > > > >
> > >> >> > > >> >> > > > > > > > >
> > >> >> > > >> >> > > > > > > > >
> > >> >> > > >> >> > > > > > > > >
> > >> >> > > >> >> > > > > > > > > >
> > >> >> > > >> >> > > > > > > > > >
> > >> >> > > >> >> > > > > > > > > > 4) Original classlib hythread do
> > >> not use
> > >> >> > > >> >> hythread_library_t in arguments,
> > >> >> > > >> >> > > > > > > > > > It uses following code:
> > >> >> > > >> >> > > > > > > > > >
> > >> >> > > >> >> > > > > > > > > > hythread_library_t lib = GLOBAL_DATA
> > >> >> > > >> >> (default_library);
> > >> >> > > >> >> > > > > > > > > > or
> > >> >> > > >> >> > > > > > > > > > hythread_library_t library = thread-
> > >> >> >library;
> > >> >> > > >> >> > > > > > > > > >
> > >> >> > > >> >> > > > > > > > > > So could you please use the same
> > >> >> mechanism and
> > >> >> > > >> >> remove hythread_*_ex >functions.
> > >> >> > > >> >> > > > > > > > > Let's see if classlib's hythread needs
> > >> >> changing first.
> > >> >> > > >> >> It seems for me
> > >> >> > > >> >> > > > > > > > > such code prevents us from having
> > >> multi VM.
> > >> >> > > >> >> > > > > > > > >
> > >> >> > > >> >> > > > > > > > > >
> > >> >> > > >> >> > > > > > > > > > 5. You introduce more then one jni
> > >> >> env, but still
> > >> >> > > >> >> use global variable for it.
> > >> >> > > >> >> > > > > > > > > > So all changes like following:
> > >> >> > > >> >> > > > > > > > > > - JNIEnv *jenv = (JNIEnv*)
> > >> >> jni_native_intf;
> > >> >> > > >> >> > > > > > > > > > + JNIEnv *jenv = jni_native_intf;
> > >> >> > > >> >> > > > > > > > > >
> > >> >> > > >> >> > > > > > > > > > should be like:
> > >> >> > > >> >> > > > > > > > > > - JNIEnv *jenv = (JNIEnv*)
> > >> >> jni_native_intf;
> > >> >> > > >> >> > > > > > > > > > + JNIEnv *jenv = get_jni_env
> > >> >> (jthread_self());
> > >> >> > > >> >> > > > > > > > >
> > >> >> > > >> >> > > > > > > > > Ok, I see. I agree that global
> > >> >> jni_native_intf should
> > >> >> > > >> >> not be used.
> > >> >> > > >> >> > > > > > > > > There was simple reason why I altered
> > >> >> such lines.
> > >> >> > > >> >> Because I changed
> > >> >> > > >> >> > > > > > > > > the type of jni_native_intf and no
> > >> >> casting operator
> > >> >> > > >> >> is needed now. To
> > >> >> > > >> >> > > > > > > > > be honest I think get_jni_env
> > >> >> (jthread_self()) can be
> > >> >> > > >> >> good as temporary
> > >> >> > > >> >> > > > > > > > > solution only. Lets wait for design of
> > >> >> multi VM and
> > >> >> > > >> >> fix it according
> > >> >> > > >> >> > > > > > > > > to it.
> > >> >> > > >> >> > > > > > > >
> > >> >> > > >> >> > > > > > > > While we are in JNI code, we always have
> > >> >> the JNIenv (at
> > >> >> > > >> >> least
> > >> >> > > >> >> > > > > > > > initially it comes from Java code). If we
> > >> >> consider VM
> > >> >> > > >> >> code as if it
> > >> >> > > >> >> > > > > > > > was a JNI application, then it seems like
> > >> >> we should be
> > >> >> > > >> >> just passing
> > >> >> > > >> >> > > > > > > > JNIEnv as a parameter to all functions in
> > >> >> VM. Or, we can
> > >> >> > > >> >> be taking it
> > >> >> > > >> >> > > > > > > > from TLS (via jthread_self()), depending
> > >> >> on which way is
> > >> >> > > >> >> faster...
> > >> >> > > >> >> > > > > > > Agree.
> > >> >> > > >> >> > > > > > >
> > >> >> > > >> >> > > > > > > >
> > >> >> > > >> >> > > > > > > > >
> > >> >> > > >> >> > > > > > > > > >
> > >> >> > > >> >> > > > > > > > > > 6). And small remarks:
> > >> >> > > >> >> > > > > > > > > > +jint vm_init1(JavaVM_Internal *
> > >> java_vm,
> > >> >> > > >> >> JavaVMInitArgs * vm_arguments);
> > >> >> > > >> >> > > > > > > > > > +jint vm_init2(JNIEnv_Internal *
> > >> >> jni_env);
> > >> >> > > >> >> > > > > > > > > > Could you make names more meaningful,
> > >> >> then 1,2,3...?
> > >> >> > > >> >> > > > > > > > > Ok, will do that.
> > >> >> > > >> >> > > > > > > > >
> > >> >> > > >> >> > > > > > > > > >
> > >> >> > > >> >> > > > > > > > > > class VM_thread {
> > >> >> > > >> >> > > > > > > > > > ...
> > >> >> > > >> >> > > > > > > > > > + JNIEnv_Internal * jni_env;
> > >> >> > > >> >> > > > > > > > > > The jthread already has the jni_env
> > >> >> pointer, you do
> > >> >> > > >> >> not need to
> > >> >> > > >> >> > > > > > > > > > duplicate it here.
> > >> >> > > >> >> > > > > > > > > > forexample by using
> > >> >> > > >> >> jthread_get_JNI_env(jthread_self());
> > >> >> > > >> >> > > > > > > > >
> > >> >> > > >> >> > > > > > > > > Yes I know. I don't see any problems
> > >> >> here. Some times
> > >> >> > > >> >> it is much more
> > >> >> > > >> >> > > > > > > > > convenient to get JNIEnv from VM_thread
> > >> >> structure (and
> > >> >> > > >> >> faster) instead
> > >> >> > > >> >> > > > > > > > > of doing jthread_get_JNI_env
> > >> (jthread_self
> > >> >> ()). So I
> > >> >> > > >> >> need strong
> > >> >> > > >> >> > > > > > > > > arguments for removing it. Again it
> > >> >> seems that should
> > >> >> > > >> >> be addressed in
> > >> >> > > >> >> > > > > > > > > design of multi VM. So lets forget about
> > >> >> it for a
> > >> >> > > >> >> while...
> > >> >> > > >> >> > > > > > > >
> > >> >> > > >> >> > > > > > > > I think that the data duplication would
> > >> >> always serve as
> > >> >> > > >> >> a potential
> > >> >> > > >> >> > > > > > > > source of errors - while updating one copy
> > >> >> of object,
> > >> >> > > >> >> you may forget
> > >> >> > > >> >> > > > > > > > to update the other, often resulting into
> > >> >> a strange
> > >> >> > > >> >> behavior of the
> > >> >> > > >> >> > > > > > > > whole application. Let's see what are the
> > >> >> specific
> > >> >> > > >> >> performance
> > >> >> > > >> >> > > > > > > > concerns that have to be addressed. To get
> > >> >> VM_thread
> > >> >> > > >> >> structure, you
> > >> >> > > >> >> > > > > > > > would eventually go to the TLS, just like
> > >> >> > > >> >> > > > > > > > jthread_get_JNI_env(jthread_self()
> > >> would do.
> > >> >> > > >> >> > > > > > > If there is already VM_thread structure for
> > >> >> some reasons
> > >> >> > > >> >> then there
> > >> >> > > >> >> > > > > > > will be no extra access to TLS. It is
> > >> >> definitely much
> > >> >> > > >> more in
> > >> >> > > >> >> > > > > > > jthread_get_JNI_env(jthread_self() than just
> > >> >> one TLS
> > >> >> > > >> >> access and one
> > >> >> > > >> >> > > > > > > dereferncing. I don't think it is a really
> > >> >> big problem
> > >> >> > > >> >> now. Do you
> > >> >> > > >> >> > > > > > > agree to look at this later. I guess
> > >> multi VM
> > >> >> > > >> >> implementation will
> > >> >> > > >> >> > > > > > > alter it in any case.
> > >> >> > > >> >> > > > > > >
> > >> >> > > >> >> > > > > > > Thanks
> > >> >> > > >> >> > > > > > > Evgueni
> > >> >> > > >> >> > > > > > >
> > >> >> > > >> >> > > > > > > >
> > >> >> > > >> >> > > > > > > > Thanks,
> > >> >> > > >> >> > > > > > > > Andrey.
> > >> >> > > >> >> > > > > > > >
> > >> >> > > >> >> > > > > > > > >
> > >> >> > > >> >> > > > > > > > > Evgueni
> > >> >> > > >> >> > > > > > > > > >
> > >> >> > > >> >> > > > > > > > > > Thanks
> > >> >> > > >> >> > > > > > > > > > Artem
> > >> >> > > >> >> > > > > > > > > >
> > >> >> > > >> >> > > > > > > > > > On 9/28/06, Evgueni Brevnov
> > >> >> > > >> >> <ev...@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.
> > >> >> > > >> >> > > > > > > > > > >
> > >> >> > > >> >> > > > > > > > > > > Thanks
> > >> >> > > >> >> > > > > > > > > > > Evgueni
> > >> >> > > >> >> > > > > > > > > > >
> > >> >> > > >> >> > > > > > > > > > > On 9/28/06, Geir Magnusson Jr.
> > >> >> <ge...@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
> > >> >> > > >> >> <we...@gmail.com> wrote:
> > >> >> > > >> >> > > > > > > > > > > > >> On 9/26/06, Evgueni Brevnov
> > >> >> > > >> >> <ev...@gmail.com> wrote:
> > >> >> > > >> >> > > > > > > > > > > > >> >
> > >> >> > > >> >> > > > > > > > > > > > >> > On 9/27/06, Andrey Chernyshev
> > >> >> > > >> >> <a....@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
> > >> >> > > >> >> > > > > > > > > > >
> > >> >> > > >> >> > > > > > > > > > >
> > >> >> > > >> >> > > > > > > > > >
> > >> >> > > >> >> > > > > > > > > >
> > >> >> > > >> >>
> > >> >>
> > >> ---------------------------------------------------------------------
> > >> >> > > >> >> > > > > > > > > > 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
> > >> >> > > >> >> > > > > > > > >
> > >> >> > > >> >> > > > > > > > >
> > >> >> > > >> >> > > > > > > >
> > >> >> > > >> >> > > > > > > >
> > >> >> > > >> >> > > > > > > > --
> > >> >> > > >> >> > > > > > > > Andrey Chernyshev
> > >> >> > > >> >> > > > > > > > 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
> > >> >> > > >> >> > > > > >
> > >> >> > > >> >> > > > > >
> > >> >> > > >> >> > > > >
> > >> >> > > >> >> > > > >
> > >> >> > > >> >> > > > > --
> > >> >> > > >> >> > > > > Andrey Chernyshev
> > >> >> > > >> >> > > > > 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
> > >> >> > > >> >> > > >
> > >> >> > > >> >> > > >
> > >> >> > > >> >> > >
> > >> >> > > >> >> > >
> > >> >> > > >> >> > > --
> > >> >> > > >> >> > > Andrey Chernyshev
> > >> >> > > >> >> > > 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
> > >> >> > > >>
> > >> >> > > >>
> > >> >> > > >
> > >> >> > > >
> > >> >>
> > >> ---------------------------------------------------------------------
> > >> >> > > > 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
> > >> >
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> 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
> >
> >
>
---------------------------------------------------------------------
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
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
Posted by Evgueni Brevnov <ev...@gmail.com>.
Could you insert sleep_a_click(); just before line 59 right after
hysem_create(&start, 0, 1):
Does it help?
On 10/9/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> [echo] ## Executing C unit test: test_ti_instrum
> [exec] Result: 1
> [echo] INFO: TEST test_jthread_get_all_threads start
> [echo] ERROR: Assertion '(thread_count)==(i +
> initial_thread_count)' failed at /home/geir/dev/apache/harmony/
> enhanced/trunk/working_vm/vm/tes
> ts/unit/thread/test_ti_instrum.c:94
> [echo] Init1: initial_thread_count=1, initial_all_threads_count=1
> [echo] Init3: initial_thread_count=1, initial_all_threads_count=1
> [echo] Init3: thread_count=3, all_threads_count=3
> [echo] INFO: TEST test_jthread_get_all_threads: FAILED
> [echo] INFO: TEST test_jthread_get_thread_count start
> [echo] Init1: initial_thread_count=3, initial_all_threads_count=3
> [echo] INFO: TEST test_jthread_get_thread_count: PASSED
> [echo] INFO: TEST test_jthread_get_blocked_count start
> [echo] INFO: TEST test_jthread_get_blocked_count: PASSED
> [echo] ## TEST FAILED
>
>
> On Oct 9, 2006, at 12:35 AM, Evgueni Brevnov wrote:
>
> > I put debug printing into test_ti_instrum.c and attached it to JIRA.
> > Could you run it on your machine and send me console output.
> >
> > Evgueni
> >
> > On 10/9/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> >> I keep getting a failure when running the tests -
> >>
> >> test_jthread_get_all-threads failling the assertion at
> >> test_ti_instrum.c:80
> >>
> >> geir
> >>
> >> On Oct 8, 2006, at 7:19 AM, Evgueni Brevnov wrote:
> >>
> >> > While running cunit on Linux it turned out one test case fails some
> >> > time. The fix is in tests.final.2.patch.
> >> >
> >> > So the last versions to be committed:
> >> > invocation_api.final.patch
> >> > build.final.2.patch
> >> > tests.final.2.patch
> >> >
> >> > Evgueni
> >> >
> >> >
> >> > On 10/8/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> >> >> I mahaged to resolve the problem on Linux.... will update
> >> >> build.final.patch with build.final.2.patch in a while
> >> >>
> >> >> On 10/8/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> >> >> > Hi,
> >> >> >
> >> >> > Oh! Ooh! I did that..... I passed cunit, somke, kernel tests on
> >> >> > Windows and smoke, kernel tests on Linux. Unfortunately I
> >> failed to
> >> >> > link cunit tests on Linux so far. So I disabled cunit on Linux
> >> >> until
> >> >> > the problem is solved. I believe it is acceptable as short term
> >> >> > solution. I found several problems in cunit tests. I will come
> >> >> up with
> >> >> > my findings later (not today).
> >> >> >
> >> >> > Use latest patches from HARMONY-1582. They are marked as final.
> >> >> There
> >> >> > are three patches. One for build module, one for cunit tests and
> >> >> one
> >> >> > for VM itself.
> >> >> >
> >> >> > Thanks
> >> >> > Evgueni
> >> >> >
> >> >> >
> >> >> > On 10/6/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> >> >> > > Nooooooo! LOL
> >> >> > >
> >> >> > > I'm here waiting - This will unblock a whole bunch of
> >> things :)
> >> >> > >
> >> >> > > Thanks for the effort
> >> >> > >
> >> >> > > Evgueni Brevnov wrote:
> >> >> > > > Geir,
> >> >> > > >
> >> >> > > > That's terrible. We have power outage....servers are down. I
> >> >> can't
> >> >> > > > send the patches now.... will do it tomorrow
> >> >> > > >
> >> >> > > > Evgueni
> >> >> > > > On 10/5/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> >> >> > > >> woo hoo! here we go...
> >> >> > > >>
> >> >> > > >>
> >> >> > > >> Andrey Chernyshev wrote:
> >> >> > > >> > Hi Evgueni,
> >> >> > > >> >
> >> >> > > >> > On 10/4/06, Evgueni Brevnov <ev...@gmail.com>
> >> >> wrote:
> >> >> > > >> >> Hi All,
> >> >> > > >> >>
> >> >> > > >> >> I have attached updated patch to the JIRA. It should
> >> >> resolve remain
> >> >> > > >> >> concerns. Andrey, could you give a green light now?
> >> >> > > >> >
> >> >> > > >> > Thanks for updating the patch! I agree it it can be
> >> >> committed, at
> >> >> > > >> > least signatures look good. 5 revisions seem like more
> >> >> than enough :).
> >> >> > > >> > Anyways, I think the remaining issues can be resolved
> >> >> with additional
> >> >> > > >> > patches. Thanks again for the good work and your
> >> patience.
> >> >> > > >> >
> >> >> > > >> > Thanks,
> >> >> > > >> > Andrey.
> >> >> > > >> >
> >> >> > > >> >>
> >> >> > > >> >> Thanks
> >> >> > > >> >> Evgueni
> >> >> > > >> >>
> >> >> > > >> >> On 10/4/06, Evgueni Brevnov <ev...@gmail.com>
> >> >> wrote:
> >> >> > > >> >> > Andrey,
> >> >> > > >> >> >
> >> >> > > >> >> > I see your points. I think both approaches have
> >> >> advantages and
> >> >> > > >> >> > disadvantages. I think it is quite hard to say which
> >> >> approach is
> >> >> > > >> >> > better until we play with one VM only. I still feel
> >> >> like introducing
> >> >> > > >> >> > one more dependence is better than spreading code
> >> >> which deals with
> >> >> > > >> >> > attachment among VM and TM. We really get stuck. OK,
> >> >> just because I
> >> >> > > >> >> > want to move forward I will do required changes to
> >> remove
> >> >> > > >> >> > vm_create_jthread from TM. I believe that will resolve
> >> >> all our
> >> >> > > >> >> > disagreements and the patch will be applied soon.
> >> >> > > >> >> >
> >> >> > > >> >> >
> >> >> > > >> >> > Thanks
> >> >> > > >> >> > Evgueni.
> >> >> > > >> >> >
> >> >> > > >> >> > On 10/4/06, Andrey Chernyshev
> >> >> <a....@gmail.com> wrote:
> >> >> > > >> >> > > On 10/3/06, Evgueni Brevnov
> >> >> <ev...@gmail.com> wrote:
> >> >> > > >> >> > > > On 10/3/06, Andrey Chernyshev
> >> >> <a....@gmail.com> wrote:
> >> >> > > >> >> > > > > On 10/2/06, Evgueni Brevnov
> >> >> <ev...@gmail.com> wrote:
> >> >> > > >> >> > > > > > Andrey,
> >> >> > > >> >> > > > > >
> >> >> > > >> >> > > > > > Just to be clear.... I agree with you it is
> >> more
> >> >> > > >> convenient if
> >> >> > > >> >> > > > > > jthread_create takes JNIEnv instead of
> >> JavaVM. It
> >> >> > > >> reflects that
> >> >> > > >> >> > > > > > current thread has been attached already. Do
> >> >> you think it
> >> >> > > >> >> makes sense
> >> >> > > >> >> > > > > > to get rid of JNIEnv and use
> >> >> jthread_get_JNI_env in that
> >> >> > > >> case?
> >> >> > > >> >> > > > >
> >> >> > > >> >> > > > > The jthread_* layer is designed like if it were
> >> >> a regular JNI
> >> >> > > >> >> > > > > application which is meant to be called from the
> >> >> Java code,
> >> >> > > >> hence
> >> >> > > >> >> > > > > every function on that layer receives JNIenv. We
> >> >> can probably
> >> >> > > >> >> get rid
> >> >> > > >> >> > > > > of the JNEnv parameter for jthread_* functions,
> >> >> assuming that
> >> >> > > >> >> TM can
> >> >> > > >> >> > > > > always extract JNIenv for the current thread
> >> with
> >> >> > > >> >> > > > > jthread_get_JNI_env().
> >> >> > > >> >> > > > > My only concern would be the performance - once
> >> >> the JNIenv is
> >> >> > > >> >> already
> >> >> > > >> >> > > > > known for the native part of the kernel classes
> >> >> impl, it
> >> >> > > >> must be
> >> >> > > >> >> > > > > cheaper to pass JNIEnv to TM as an extra
> >> >> parameter rather than
> >> >> > > >> >> extract
> >> >> > > >> >> > > > > it from the TLS again.
> >> >> > > >> >> > > > > Other than that, I see no strong advantages in
> >> >> keeping JNIEnv
> >> >> > > >> >> parameter.
> >> >> > > >> >> > > > >
> >> >> > > >> >> > > > >
> >> >> > > >> >> > > > > > Regarding jthread_attach. I still didn't get
> >> >> your point....
> >> >> > > >> >> Clarify it
> >> >> > > >> >> > > > > > please if you think jhread_attach should be
> >> >> modified.
> >> >> > > >> >> > > > >
> >> >> > > >> >> > > > > Sorry for being not clear: I think for
> >> >> jthread_attach, we have
> >> >> > > >> >> two options:
> >> >> > > >> >> > > > > 1) Make JNIEnv input parameter - it must be new
> >> >> JNIEnv that VM
> >> >> > > >> >> > > > > pre-allocates for the new Java thread.
> >> >> jthread_attach
> >> >> > > >> would just
> >> >> > > >> >> > > > > associate it with the current thread.
> >> >> > > >> >> > > > >
> >> >> > > >> >> > > > > 2) Obtain JNIEnv via vm_attach() callback. In
> >> >> this case, if
> >> >> > > >> >> > > > > vm_attach() callback implementation needs to
> >> >> know for which
> >> >> > > >> >> JavaVM new
> >> >> > > >> >> > > > > JNIenv has to be allocated, then we'll need to
> >> >> add JavaVM as
> >> >> > > >> >> input
> >> >> > > >> >> > > > > parameter for jthread_attach().
> >> >> > > >> >> > > > > I think both options should be fine, (1) would
> >> >> probably
> >> >> > > >> keep TM
> >> >> > > >> >> > > > > interface a bit lighter, though (2) may look
> >> >> more closer to
> >> >> > > >> >> the JNI
> >> >> > > >> >> > > > > invocation API idea.
> >> >> > > >> >> > > > > So I think adding JavaVM specifically for
> >> >> jthread_attach
> >> >> > > >> may make
> >> >> > > >> >> > > > > sense given the explanation you provided
> >> earlier.
> >> >> > > >> >> > > > >
> >> >> > > >> >> > > > > The concern I would have regarding the proposed
> >> >> jthread_attach
> >> >> > > >> >> > > > > implementation is a call to vm_create_jthread()
> >> >> - this call
> >> >> > > >> >> introduces
> >> >> > > >> >> > > > > an extra dependency of TM on vmcore that I'd
> >> >> prefer to be
> >> >> > > >> >> avoided. In
> >> >> > > >> >> > > > > the original version, jthread_attach() was
> >> >> taking jthread
> >> >> > > >> >> argument of
> >> >> > > >> >> > > > > the already prepared j.l.Thread.
> >> >> > > >> >> > > >
> >> >> > > >> >> > > > I understand your concern. Unfortunately I don't
> >> >> see what we
> >> >> > > >> can do
> >> >> > > >> >> > > > here. Let me explain. In the beginning you have an
> >> >> unattached
> >> >> > > >> >> native
> >> >> > > >> >> > > > thread. To be able to call java code (which is
> >> >> required for
> >> >> > > >> >> > > > constructing j.l.Thread instance) the thread
> >> >> should be attached
> >> >> > > >> >> first.
> >> >> > > >> >> > > > To be specific it should be attached to VM by
> >> >> calling vm_attach
> >> >> > > >> >> which
> >> >> > > >> >> > > > will return a valid JNIEnv It is valid to use JNI
> >> >> from that
> >> >> > > >> moment.
> >> >> > > >> >> > > > Obtained JNIEnv can be used to execute java code
> >> >> and create
> >> >> > > >> >> j.l.Thread
> >> >> > > >> >> > > > instance. Since we do vm_attach in jthread_attach
> >> >> we need to do
> >> >> > > >> >> > > > vm_create_jthread inside jthread_atach as well.
> >> >> > > >> >> > > > Of course it can be an alternative to do vm_attach
> >> >> and
> >> >> > > >> >> > > > vm_create_jthread outside of TM right before
> >> >> jthread_attach.
> >> >> > > >> >> Sure it
> >> >> > > >> >> > > > will reduce one dependence between VM and TM. But
> >> >> it seems like
> >> >> > > >> >> > > > artificial action for me just because of
> >> >> dependency....
> >> >> > > >> >> > >
> >> >> > > >> >> > > Why do you think it is artificial? I would rather
> >> >> prefer not to
> >> >> > > >> throw
> >> >> > > >> >> > > vm_attach event from the jthread_attach() call at
> >> >> all than to add
> >> >> > > >> >> > > extra dependency. The idea of jthread layer is a
> >> >> Java face to
> >> >> > > >> >> > > hythread, it is meant to know either a little or
> >> >> nothing about the
> >> >> > > >> >> > > rest of VM. It may be logical to throw vm_attach
> >> >> call from the
> >> >> > > >> newly
> >> >> > > >> >> > > created thread, because there is no other way to let
> >> >> know VM
> >> >> > > >> the new
> >> >> > > >> >> > > thread is created. VM attach is a different case -
> >> >> VM already
> >> >> > > >> knows
> >> >> > > >> >> > > about new Java thread at the time of the
> >> >> AttachCurrentThread call.
> >> >> > > >> >> > >
> >> >> > > >> >> > > >
> >> >> > > >> >> > > > > Do you think it makes sense to replace a single
> >> >> jthread
> >> >> > > >> >> parameter with
> >> >> > > >> >> > > > > a variety of stuff (like thread group, name)? It
> >> >> seems the
> >> >> > > >> only
> >> >> > > >> >> > > > > purpose of at these args is to be passed back to
> >> >> VM for
> >> >> > > >> >> > > > > vm_jthread_create(). I would suggest to change
> >> >> this and try
> >> >> > > >> doing
> >> >> > > >> >> > > > > either of:
> >> >> > > >> >> > > > > 1) Make signature of jthread_attach with 3 args,
> >> >> JavaVM,
> >> >> > > >> >> jthread and the daemon.
> >> >> > > >> >> > > > Why do you want to pass daemon to TM but thread's
> >> >> name and
> >> >> > > >> >> group. Just
> >> >> > > >> >> > > > because current TM doesn't need such information?
> >> >> What if it is
> >> >> > > >> >> > > > required to get thread name later? Say by
> >> introducing
> >> >> > > >> >> > >
> >> >> > > >> >> > > I imagine you need a daemon attribute since the TM
> >> >> is still
> >> >> > > >> managing
> >> >> > > >> >> > > the thread daemonality. TM is not managing thread
> >> >> name and group -
> >> >> > > >> >> > > they are all kept on the Java level, hence passing
> >> >> them may be
> >> >> > > >> >> > > excessive.
> >> >> > > >> >> > >
> >> >> > > >> >> > > > jthread_get_name... What will you do in that case?
> >> >> Let me
> >> >> > > >> guess you
> >> >> > > >> >> > > > will call j.l.Thread.getName. Right. Ok! In that
> >> >> case I see no
> >> >> > > >> >> > > > problems to call j.l.Thread.isDaemon. Do you
> >> >> agree? So it
> >> >> > > >> doesn't
> >> >> > > >> >> > >
> >> >> > > >> >> > > As I suggested earlier, the best way to handle
> >> >> daemonality would
> >> >> > > >> >> > > probably be in pure Java - in j.l.Thread (or
> >> >> > > >> j.l.VMThreadManager) or
> >> >> > > >> >> > > whatever. You already lifted it up to the jthread
> >> >> level, but
> >> >> > > >> what if
> >> >> > > >> >> > > we can go a little bit higher...
> >> >> > > >> >> > >
> >> >> > > >> >> > > > seems to be a good design to pass only part of the
> >> >> > > >> information to
> >> >> > > >> >> > > > jthread_atach. Lets look at the signature of
> >> >> > > >> >> AttachCurrentThread. It
> >> >> > > >> >> > > > takes exactly these three parameters (daemon,
> >> >> name, group)
> >> >> > > >> >> passed as a
> >> >> > > >> >> > > > structure. I was thinking about having exactly the
> >> >> same
> >> >> > > >> >> structure as
> >> >> > > >> >> > > > third parameter of jthread_attach but it occured
> >> >> to be more
> >> >> > > >> >> convinient
> >> >> > > >> >> > > > to pass them seperatly. Although I don't see
> >> >> strong reasons
> >> >> > > >> against
> >> >> > > >> >> > > > having a structure a third parameter.
> >> >> > > >> >> > >
> >> >> > > >> >> > > I see. Acually, I would love to keep the
> >> >> jthread_attach func-ty at
> >> >> > > >> >> the
> >> >> > > >> >> > > minimum level which will be needed to handle the
> >> >> only data that TM
> >> >> > > >> >> > > should be aware of. We need a formal boundary
> >> >> between jthread
> >> >> > > >> layer
> >> >> > > >> >> > > and vmcore (otherwise jthread won't have a much of
> >> >> sense, one may
> >> >> > > >> >> > > consider it just as a convenience set of functions
> >> >> in vmcore which
> >> >> > > >> >> are
> >> >> > > >> >> > > doing something with threading).
> >> >> > > >> >> > >
> >> >> > > >> >> > > >
> >> >> > > >> >> > > > > 2) Move the implementation of vm_create_jtrhead
> >> >> () to
> >> >> > > >> >> > > > > thread_java_basic.c - could it be written in
> >> >> pure JNI without
> >> >> > > >> >> using
> >> >> > > >> >> > > > > internal VM API like class_alloc_new_object()?
> >> >> > > >> >> > > >
> >> >> > > >> >> > > > Yes, this can be done but it doesn't fix the
> >> >> problem. You still
> >> >> > > >> >> need
> >> >> > > >> >> > > > to know about internal constructor of j.l.Thread
> >> >> > > >> >> > >
> >> >> > > >> >> > > That's bad. Given what you said, now it seems that
> >> >> the most
> >> >> > > >> >> preferable
> >> >> > > >> >> > > sequence for AttachCurrentThread impl still would be
> >> >> like:
> >> >> > > >> >> > > JNIEnv = vm_attach();
> >> >> > > >> >> > > jthread = create_jthread(JNIenv)
> >> >> > > >> >> > > jthread_attach(JNIEnv, jthread) // stores JNIEnv and
> >> >> Hythread into
> >> >> > > >> >> > > TLS, doesn't call vm_attach any longer.
> >> >> > > >> >> > > - this is almost what we had from the beginning...
> >> >> > > >> >> > >
> >> >> > > >> >> > > Thanks,
> >> >> > > >> >> > > Andrey.
> >> >> > > >> >> > >
> >> >> > > >> >> > > >
> >> >> > > >> >> > > >
> >> >> > > >> >> > > > Thanks
> >> >> > > >> >> > > > Evgueni
> >> >> > > >> >> > > > >
> >> >> > > >> >> > > > >
> >> >> > > >> >> > > > > Thanks,
> >> >> > > >> >> > > > > Andrey.
> >> >> > > >> >> > > > >
> >> >> > > >> >> > > > > >
> >> >> > > >> >> > > > > > Thank you
> >> >> > > >> >> > > > > > Evgueni
> >> >> > > >> >> > > > > >
> >> >> > > >> >> > > > > > On 10/2/06, Evgueni Brevnov
> >> >> <ev...@gmail.com>
> >> >> > > >> wrote:
> >> >> > > >> >> > > > > > > On 9/29/06, Andrey Chernyshev
> >> >> <a....@gmail.com>
> >> >> > > >> >> wrote:
> >> >> > > >> >> > > > > > > > On 9/29/06, Evgueni Brevnov
> >> >> <ev...@gmail.com>
> >> >> > > >> >> wrote:
> >> >> > > >> >> > > > > > > > > Artem,
> >> >> > > >> >> > > > > > > > >
> >> >> > > >> >> > > > > > > > > Thank you for your feedback.... find my
> >> >> inlined.....
> >> >> > > >> >> > > > > > > > >
> >> >> > > >> >> > > > > > > > > On 9/29/06, Artem Aliev
> >> >> <ar...@gmail.com> wrote:
> >> >> > > >> >> > > > > > > > > > Evgueni,
> >> >> > > >> >> > > > > > > > > >
> >> >> > > >> >> > > > > > > > > > I got most of your changes, but still
> >> >> disagree
> >> >> > > >> with all
> >> >> > > >> >> > > > > > > > > > hythread/jthread interface changes.
> >> >> Could leave
> >> >> > > >> >> interface unchanged.
> >> >> > > >> >> > > > > > > > > > See following possible solutions, that
> >> >> could solve
> >> >> > > >> >> the same problems
> >> >> > > >> >> > > > > > > > > > without interface changes.
> >> >> > > >> >> > > > > > > > > >
> >> >> > > >> >> > > > > > > > > >
> >> >> > > >> >> > > > > > > > > > 1) daemon attribute is a java
> >> >> specific. (Andrey
> >> >> > > >> >> mentioned this already).
> >> >> > > >> >> > > > > > > > > > Could you please move it back. to
> >> >> the jthread
> >> >> > > >> >> layer. It is better
> >> >> > > >> >> > > > > > > > > > to rename
> >> >> > > >> >> > > > > > > > > >
> >> >> hythread_wait_for_all_nondaemon_threads() to
> >> >> > > >> >> > > > > > > > > >
> >> jthread_wait_for_all_nondaemon_threads().
> >> >> > > >> >> > > > > > > > > Ok, I see no problems to move "daemon"
> >> >> to java layer.
> >> >> > > >> >> In that case:
> >> >> > > >> >> > > > > > > > > 1) I will move
> >> >> > > >> >> hythread_wait_for_all_nondaemon_threads() from
> >> >> > > >> >> > > > > > > > > thread_init.c to one which implements
> >> >> java layer.
> >> >> > > >> >> > > > > > > > > 2) I will move daemon field from
> >> >> HyThread structure.
> >> >> > > >> >> > > > > > > > >
> >> >> > > >> >> > > > > > > > > Agree?
> >> >> > > >> >> > > > > > > >
> >> >> > > >> >> > > > > > > > Sounds good to me.
> >> >> > > >> >> > > > > > >
> >> >> > > >> >> > > > > > > OK, will do that.
> >> >> > > >> >> > > > > > >
> >> >> > > >> >> > > > > > > >
> >> >> > > >> >> > > > > > > >
> >> >> > > >> >> > > > > > > > >
> >> >> > > >> >> > > > > > > > > >
> >> >> > > >> >> > > > > > > > > > 2) JavaVM could be retrieved from
> >> >> JNIEnv by
> >> >> > > >> >> jni_get_java_vm(). So
> >> >> > > >> >> > > > > > > > > > let the jthread_create() and others to
> >> >> use JNIEnv
> >> >> > > >> >> (that is passed from
> >> >> > > >> >> > > > > > > > > > java native method).
> >> >> > > >> >> > > > > > > > > > The vm_attach could get old JNI env
> >> >> and create new
> >> >> > > >> >> one for the new thread.
> >> >> > > >> >> > > > > > > > > > The first JNIEnv is created in
> >> >> CreateVM call and
> >> >> > > >> >> could be passed to
> >> >> > > >> >> > > > > > > > > > the first thread at startup.
> >> >> > > >> >> > > > > > > > > No, no, no. I completely disagree with
> >> >> that!!! Why do
> >> >> > > >> >> you like JNIEnv
> >> >> > > >> >> > > > > > > > > but JavaVM. Why do you think that
> >> >> passing JavaVM
> >> >> > > >> >> instead of JNIEnv
> >> >> > > >> >> > > > > > > > > makes TM less modular? I don't see any
> >> >> difference
> >> >> > > >> >> here.... It seems
> >> >> > > >> >> > > > > > > > > for me like a big big hack to grab
> >> >> JNIEnv from another
> >> >> > > >> >> thread and pass
> >> >> > > >> >> > > > > > > > > it to jthread_attach to perform
> >> >> operations in the
> >> >> > > >> >> current thread.
> >> >> > > >> >> > > > > > > >
> >> >> > > >> >> > > > > > > > TM needs to know JNIEnv, mainly for
> >> >> managing the
> >> >> > > >> >> references to
> >> >> > > >> >> > > > > > > > objects, throwing exceptions and calling
> >> >> run() method of
> >> >> > > >> >> a new thread.
> >> >> > > >> >> > > > > > > > JNI spec proposes that JNIEnv is valid
> >> >> within the given
> >> >> > > >> >> thread, this
> >> >> > > >> >> > > > > > > > is why TM holds the JNIEnv pointer at the
> >> >> moment. This
> >> >> > > >> >> is why TM likes
> >> >> > > >> >> > > > > > > > the JNIEnv.
> >> >> > > >> >> > > > > > > >
> >> >> > > >> >> > > > > > > > Having the JNIEnv, one is able to get
> >> >> JavaVM but not
> >> >> > > >> >> vise versa. This
> >> >> > > >> >> > > > > > > > is why TM doesn't like the JavaVM :)
> >> >> > > >> >> > > > > > > I see your point. Only one note this is true
> >> >> for already
> >> >> > > >> >> attached threads...
> >> >> > > >> >> > > > > > >
> >> >> > > >> >> > > > > > > >
> >> >> > > >> >> > > > > > > > I agree with you that there is a design
> >> >> flaw that the
> >> >> > > >> >> JNIEnv is copied
> >> >> > > >> >> > > > > > > > from the parent thread to a child thread
> >> >> during thread
> >> >> > > >> >> creation. I
> >> >> > > >> >> > > > > > > > think it could be resolved via vm_attach()
> >> >> hook - with
> >> >> > > >> >> this event, VM
> >> >> > > >> >> > > > > > > > might tell the TM what the JNIEnv pointer
> >> >> for new thread
> >> >> > > >> >> should be. I
> >> >> > > >> >> > > > > > > > think you did that by extending the
> >> >> vm_attach() call
> >> >> > > >> >> with the JNIEnv**
> >> >> > > >> >> > > > > > > > argument.
> >> >> > > >> >> > > > > > > >
> >> >> > > >> >> > > > > > > > What is not completely clear is, why do
> >> >> you have to pass
> >> >> > > >> >> the JavaVM
> >> >> > > >> >> > > > > > > > forth and back, once from VM to TM, and
> >> >> then back from
> >> >> > > >> >> TM to VM again?
> >> >> > > >> >> > > > > > > >
> >> >> > > >> >> > > > > > > > If you need to know in jthread_attach,
> >> >> which particular
> >> >> > > >> >> VM vm_attach()
> >> >> > > >> >> > > > > > > > event is coming from, you could have
> >> >> vm_attach like
> >> >> > > >> >> > > > > > > > vm_attach(JNIEnv* currentThreadEnv,
> >> JNIEnv**
> >> >> > > >> >> newThreadEnv).
> >> >> > > >> >> > > > > > > I'm a little bit confused.....Current thread
> >> >> hasn't been
> >> >> > > >> >> attached yet.
> >> >> > > >> >> > > > > > > So there is no JNIEnv for it yet. How it can
> >> >> be passed as
> >> >> > > >> >> the first
> >> >> > > >> >> > > > > > > parameter to vm_attach()?
> >> >> > > >> >> > > > > > >
> >> >> > > >> >> > > > > > > > Then you will be always able to get the
> >> >> JavaVM from the
> >> >> > > >> >> JNIEnv.
> >> >> > > >> >> > > > > > > > The only difference is that you are
> >> >> currently doing
> >> >> > > >> >> JNIEnv->JavaVM
> >> >> > > >> >> > > > > > > > conversion in the VMThreadManager, but why
> >> >> can't you
> >> >> > > >> >> just do this in
> >> >> > > >> >> > > > > > > > vm_attach() without changing the interface
> >> >> of the TM?
> >> >> > > >> >> > > > > > > > So far JavaVM really looks like an extra
> >> >> knowledge that
> >> >> > > >> >> TM doesn't
> >> >> > > >> >> > > > > > > > have to be aware of.
> >> >> > > >> >> > > > > > > >
> >> >> > > >> >> > > > > > > > > Moreover there is no JNIEnv when main
> >> >> thread attaches
> >> >> > > >> >> to VM. So we
> >> >> > > >> >> > > > > > > > > should either keep it as is or change
> >> >> original design
> >> >> > > >> >> of TM and attach
> >> >> > > >> >> > > > > > > > > thread to VM before attaching it to TM.
> >> >> In that case
> >> >> > > >> >> we will have
> >> >> > > >> >> > > > > > > > > valid JNIEnv which can be passed to
> >> >> jthread_atatch. We
> >> >> > > >> >> need to think
> >> >> > > >> >> > > > > > > > > over it twice before changing
> >> something....
> >> >> > > >> >> > > > > > > >
> >> >> > > >> >> > > > > > > > Right. For jthread_attach, JNIenv needs to
> >> >> be changed
> >> >> > > >> >> from being input
> >> >> > > >> >> > > > > > > > parameter to being the output parameter.
> >> >> The way how
> >> >> > > >> >> JNIenv is
> >> >> > > >> >> > > > > > > > obtained by TM should be vm_attach()
> >> event.
> >> >> > > >> >> > > > > > > OK, JNIEnv is output parameter. And it
> >> >> obtained by
> >> >> > > >> >> vm_attach(). This
> >> >> > > >> >> > > > > > > is exactly like I do in the patch. What I
> >> >> don't understand
> >> >> > > >> >> is how
> >> >> > > >> >> > > > > > > jthread_attach knows to which VM the thread
> >> >> should be
> >> >> > > >> >> attached? Do you
> >> >> > > >> >> > > > > > > suggest calling vm_attach first to create
> >> >> JNIEnv it pass
> >> >> > > >> >> it to
> >> >> > > >> >> > > > > > > jthread_attach?
> >> >> > > >> >> > > > > > >
> >> >> > > >> >> > > > > > > >
> >> >> > > >> >> > > > > > > > >
> >> >> > > >> >> > > > > > > > >
> >> >> > > >> >> > > > > > > > >
> >> >> > > >> >> > > > > > > > > >
> >> >> > > >> >> > > > > > > > > >
> >> >> > > >> >> > > > > > > > > > 4) Original classlib hythread do
> >> not use
> >> >> > > >> >> hythread_library_t in arguments,
> >> >> > > >> >> > > > > > > > > > It uses following code:
> >> >> > > >> >> > > > > > > > > >
> >> >> > > >> >> > > > > > > > > > hythread_library_t lib = GLOBAL_DATA
> >> >> > > >> >> (default_library);
> >> >> > > >> >> > > > > > > > > > or
> >> >> > > >> >> > > > > > > > > > hythread_library_t library = thread-
> >> >> >library;
> >> >> > > >> >> > > > > > > > > >
> >> >> > > >> >> > > > > > > > > > So could you please use the same
> >> >> mechanism and
> >> >> > > >> >> remove hythread_*_ex >functions.
> >> >> > > >> >> > > > > > > > > Let's see if classlib's hythread needs
> >> >> changing first.
> >> >> > > >> >> It seems for me
> >> >> > > >> >> > > > > > > > > such code prevents us from having
> >> multi VM.
> >> >> > > >> >> > > > > > > > >
> >> >> > > >> >> > > > > > > > > >
> >> >> > > >> >> > > > > > > > > > 5. You introduce more then one jni
> >> >> env, but still
> >> >> > > >> >> use global variable for it.
> >> >> > > >> >> > > > > > > > > > So all changes like following:
> >> >> > > >> >> > > > > > > > > > - JNIEnv *jenv = (JNIEnv*)
> >> >> jni_native_intf;
> >> >> > > >> >> > > > > > > > > > + JNIEnv *jenv = jni_native_intf;
> >> >> > > >> >> > > > > > > > > >
> >> >> > > >> >> > > > > > > > > > should be like:
> >> >> > > >> >> > > > > > > > > > - JNIEnv *jenv = (JNIEnv*)
> >> >> jni_native_intf;
> >> >> > > >> >> > > > > > > > > > + JNIEnv *jenv = get_jni_env
> >> >> (jthread_self());
> >> >> > > >> >> > > > > > > > >
> >> >> > > >> >> > > > > > > > > Ok, I see. I agree that global
> >> >> jni_native_intf should
> >> >> > > >> >> not be used.
> >> >> > > >> >> > > > > > > > > There was simple reason why I altered
> >> >> such lines.
> >> >> > > >> >> Because I changed
> >> >> > > >> >> > > > > > > > > the type of jni_native_intf and no
> >> >> casting operator
> >> >> > > >> >> is needed now. To
> >> >> > > >> >> > > > > > > > > be honest I think get_jni_env
> >> >> (jthread_self()) can be
> >> >> > > >> >> good as temporary
> >> >> > > >> >> > > > > > > > > solution only. Lets wait for design of
> >> >> multi VM and
> >> >> > > >> >> fix it according
> >> >> > > >> >> > > > > > > > > to it.
> >> >> > > >> >> > > > > > > >
> >> >> > > >> >> > > > > > > > While we are in JNI code, we always have
> >> >> the JNIenv (at
> >> >> > > >> >> least
> >> >> > > >> >> > > > > > > > initially it comes from Java code). If we
> >> >> consider VM
> >> >> > > >> >> code as if it
> >> >> > > >> >> > > > > > > > was a JNI application, then it seems like
> >> >> we should be
> >> >> > > >> >> just passing
> >> >> > > >> >> > > > > > > > JNIEnv as a parameter to all functions in
> >> >> VM. Or, we can
> >> >> > > >> >> be taking it
> >> >> > > >> >> > > > > > > > from TLS (via jthread_self()), depending
> >> >> on which way is
> >> >> > > >> >> faster...
> >> >> > > >> >> > > > > > > Agree.
> >> >> > > >> >> > > > > > >
> >> >> > > >> >> > > > > > > >
> >> >> > > >> >> > > > > > > > >
> >> >> > > >> >> > > > > > > > > >
> >> >> > > >> >> > > > > > > > > > 6). And small remarks:
> >> >> > > >> >> > > > > > > > > > +jint vm_init1(JavaVM_Internal *
> >> java_vm,
> >> >> > > >> >> JavaVMInitArgs * vm_arguments);
> >> >> > > >> >> > > > > > > > > > +jint vm_init2(JNIEnv_Internal *
> >> >> jni_env);
> >> >> > > >> >> > > > > > > > > > Could you make names more meaningful,
> >> >> then 1,2,3...?
> >> >> > > >> >> > > > > > > > > Ok, will do that.
> >> >> > > >> >> > > > > > > > >
> >> >> > > >> >> > > > > > > > > >
> >> >> > > >> >> > > > > > > > > > class VM_thread {
> >> >> > > >> >> > > > > > > > > > ...
> >> >> > > >> >> > > > > > > > > > + JNIEnv_Internal * jni_env;
> >> >> > > >> >> > > > > > > > > > The jthread already has the jni_env
> >> >> pointer, you do
> >> >> > > >> >> not need to
> >> >> > > >> >> > > > > > > > > > duplicate it here.
> >> >> > > >> >> > > > > > > > > > forexample by using
> >> >> > > >> >> jthread_get_JNI_env(jthread_self());
> >> >> > > >> >> > > > > > > > >
> >> >> > > >> >> > > > > > > > > Yes I know. I don't see any problems
> >> >> here. Some times
> >> >> > > >> >> it is much more
> >> >> > > >> >> > > > > > > > > convenient to get JNIEnv from VM_thread
> >> >> structure (and
> >> >> > > >> >> faster) instead
> >> >> > > >> >> > > > > > > > > of doing jthread_get_JNI_env
> >> (jthread_self
> >> >> ()). So I
> >> >> > > >> >> need strong
> >> >> > > >> >> > > > > > > > > arguments for removing it. Again it
> >> >> seems that should
> >> >> > > >> >> be addressed in
> >> >> > > >> >> > > > > > > > > design of multi VM. So lets forget about
> >> >> it for a
> >> >> > > >> >> while...
> >> >> > > >> >> > > > > > > >
> >> >> > > >> >> > > > > > > > I think that the data duplication would
> >> >> always serve as
> >> >> > > >> >> a potential
> >> >> > > >> >> > > > > > > > source of errors - while updating one copy
> >> >> of object,
> >> >> > > >> >> you may forget
> >> >> > > >> >> > > > > > > > to update the other, often resulting into
> >> >> a strange
> >> >> > > >> >> behavior of the
> >> >> > > >> >> > > > > > > > whole application. Let's see what are the
> >> >> specific
> >> >> > > >> >> performance
> >> >> > > >> >> > > > > > > > concerns that have to be addressed. To get
> >> >> VM_thread
> >> >> > > >> >> structure, you
> >> >> > > >> >> > > > > > > > would eventually go to the TLS, just like
> >> >> > > >> >> > > > > > > > jthread_get_JNI_env(jthread_self()
> >> would do.
> >> >> > > >> >> > > > > > > If there is already VM_thread structure for
> >> >> some reasons
> >> >> > > >> >> then there
> >> >> > > >> >> > > > > > > will be no extra access to TLS. It is
> >> >> definitely much
> >> >> > > >> more in
> >> >> > > >> >> > > > > > > jthread_get_JNI_env(jthread_self() than just
> >> >> one TLS
> >> >> > > >> >> access and one
> >> >> > > >> >> > > > > > > dereferncing. I don't think it is a really
> >> >> big problem
> >> >> > > >> >> now. Do you
> >> >> > > >> >> > > > > > > agree to look at this later. I guess
> >> multi VM
> >> >> > > >> >> implementation will
> >> >> > > >> >> > > > > > > alter it in any case.
> >> >> > > >> >> > > > > > >
> >> >> > > >> >> > > > > > > Thanks
> >> >> > > >> >> > > > > > > Evgueni
> >> >> > > >> >> > > > > > >
> >> >> > > >> >> > > > > > > >
> >> >> > > >> >> > > > > > > > Thanks,
> >> >> > > >> >> > > > > > > > Andrey.
> >> >> > > >> >> > > > > > > >
> >> >> > > >> >> > > > > > > > >
> >> >> > > >> >> > > > > > > > > Evgueni
> >> >> > > >> >> > > > > > > > > >
> >> >> > > >> >> > > > > > > > > > Thanks
> >> >> > > >> >> > > > > > > > > > Artem
> >> >> > > >> >> > > > > > > > > >
> >> >> > > >> >> > > > > > > > > > On 9/28/06, Evgueni Brevnov
> >> >> > > >> >> <ev...@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.
> >> >> > > >> >> > > > > > > > > > >
> >> >> > > >> >> > > > > > > > > > > Thanks
> >> >> > > >> >> > > > > > > > > > > Evgueni
> >> >> > > >> >> > > > > > > > > > >
> >> >> > > >> >> > > > > > > > > > > On 9/28/06, Geir Magnusson Jr.
> >> >> <ge...@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
> >> >> > > >> >> <we...@gmail.com> wrote:
> >> >> > > >> >> > > > > > > > > > > > >> On 9/26/06, Evgueni Brevnov
> >> >> > > >> >> <ev...@gmail.com> wrote:
> >> >> > > >> >> > > > > > > > > > > > >> >
> >> >> > > >> >> > > > > > > > > > > > >> > On 9/27/06, Andrey Chernyshev
> >> >> > > >> >> <a....@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
> >> >> > > >> >> > > > > > > > > > >
> >> >> > > >> >> > > > > > > > > > >
> >> >> > > >> >> > > > > > > > > >
> >> >> > > >> >> > > > > > > > > >
> >> >> > > >> >>
> >> >>
> >> ---------------------------------------------------------------------
> >> >> > > >> >> > > > > > > > > > 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
> >> >> > > >> >> > > > > > > > >
> >> >> > > >> >> > > > > > > > >
> >> >> > > >> >> > > > > > > >
> >> >> > > >> >> > > > > > > >
> >> >> > > >> >> > > > > > > > --
> >> >> > > >> >> > > > > > > > Andrey Chernyshev
> >> >> > > >> >> > > > > > > > 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
> >> >> > > >> >> > > > > >
> >> >> > > >> >> > > > > >
> >> >> > > >> >> > > > >
> >> >> > > >> >> > > > >
> >> >> > > >> >> > > > > --
> >> >> > > >> >> > > > > Andrey Chernyshev
> >> >> > > >> >> > > > > 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
> >> >> > > >> >> > > >
> >> >> > > >> >> > > >
> >> >> > > >> >> > >
> >> >> > > >> >> > >
> >> >> > > >> >> > > --
> >> >> > > >> >> > > Andrey Chernyshev
> >> >> > > >> >> > > 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
> >> >> > > >>
> >> >> > > >>
> >> >> > > >
> >> >> > > >
> >> >>
> >> ---------------------------------------------------------------------
> >> >> > > > 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
> >> >
> >>
> >>
> >> ---------------------------------------------------------------------
> >> 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
>
>
---------------------------------------------------------------------
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
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
[echo] ## Executing C unit test: test_ti_instrum
[exec] Result: 1
[echo] INFO: TEST test_jthread_get_all_threads start
[echo] ERROR: Assertion '(thread_count)==(i +
initial_thread_count)' failed at /home/geir/dev/apache/harmony/
enhanced/trunk/working_vm/vm/tes
ts/unit/thread/test_ti_instrum.c:94
[echo] Init1: initial_thread_count=1, initial_all_threads_count=1
[echo] Init3: initial_thread_count=1, initial_all_threads_count=1
[echo] Init3: thread_count=3, all_threads_count=3
[echo] INFO: TEST test_jthread_get_all_threads: FAILED
[echo] INFO: TEST test_jthread_get_thread_count start
[echo] Init1: initial_thread_count=3, initial_all_threads_count=3
[echo] INFO: TEST test_jthread_get_thread_count: PASSED
[echo] INFO: TEST test_jthread_get_blocked_count start
[echo] INFO: TEST test_jthread_get_blocked_count: PASSED
[echo] ## TEST FAILED
On Oct 9, 2006, at 12:35 AM, Evgueni Brevnov wrote:
> I put debug printing into test_ti_instrum.c and attached it to JIRA.
> Could you run it on your machine and send me console output.
>
> Evgueni
>
> On 10/9/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>> I keep getting a failure when running the tests -
>>
>> test_jthread_get_all-threads failling the assertion at
>> test_ti_instrum.c:80
>>
>> geir
>>
>> On Oct 8, 2006, at 7:19 AM, Evgueni Brevnov wrote:
>>
>> > While running cunit on Linux it turned out one test case fails some
>> > time. The fix is in tests.final.2.patch.
>> >
>> > So the last versions to be committed:
>> > invocation_api.final.patch
>> > build.final.2.patch
>> > tests.final.2.patch
>> >
>> > Evgueni
>> >
>> >
>> > On 10/8/06, Evgueni Brevnov <ev...@gmail.com> wrote:
>> >> I mahaged to resolve the problem on Linux.... will update
>> >> build.final.patch with build.final.2.patch in a while
>> >>
>> >> On 10/8/06, Evgueni Brevnov <ev...@gmail.com> wrote:
>> >> > Hi,
>> >> >
>> >> > Oh! Ooh! I did that..... I passed cunit, somke, kernel tests on
>> >> > Windows and smoke, kernel tests on Linux. Unfortunately I
>> failed to
>> >> > link cunit tests on Linux so far. So I disabled cunit on Linux
>> >> until
>> >> > the problem is solved. I believe it is acceptable as short term
>> >> > solution. I found several problems in cunit tests. I will come
>> >> up with
>> >> > my findings later (not today).
>> >> >
>> >> > Use latest patches from HARMONY-1582. They are marked as final.
>> >> There
>> >> > are three patches. One for build module, one for cunit tests and
>> >> one
>> >> > for VM itself.
>> >> >
>> >> > Thanks
>> >> > Evgueni
>> >> >
>> >> >
>> >> > On 10/6/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>> >> > > Nooooooo! LOL
>> >> > >
>> >> > > I'm here waiting - This will unblock a whole bunch of
>> things :)
>> >> > >
>> >> > > Thanks for the effort
>> >> > >
>> >> > > Evgueni Brevnov wrote:
>> >> > > > Geir,
>> >> > > >
>> >> > > > That's terrible. We have power outage....servers are down. I
>> >> can't
>> >> > > > send the patches now.... will do it tomorrow
>> >> > > >
>> >> > > > Evgueni
>> >> > > > On 10/5/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>> >> > > >> woo hoo! here we go...
>> >> > > >>
>> >> > > >>
>> >> > > >> Andrey Chernyshev wrote:
>> >> > > >> > Hi Evgueni,
>> >> > > >> >
>> >> > > >> > On 10/4/06, Evgueni Brevnov <ev...@gmail.com>
>> >> wrote:
>> >> > > >> >> Hi All,
>> >> > > >> >>
>> >> > > >> >> I have attached updated patch to the JIRA. It should
>> >> resolve remain
>> >> > > >> >> concerns. Andrey, could you give a green light now?
>> >> > > >> >
>> >> > > >> > Thanks for updating the patch! I agree it it can be
>> >> committed, at
>> >> > > >> > least signatures look good. 5 revisions seem like more
>> >> than enough :).
>> >> > > >> > Anyways, I think the remaining issues can be resolved
>> >> with additional
>> >> > > >> > patches. Thanks again for the good work and your
>> patience.
>> >> > > >> >
>> >> > > >> > Thanks,
>> >> > > >> > Andrey.
>> >> > > >> >
>> >> > > >> >>
>> >> > > >> >> Thanks
>> >> > > >> >> Evgueni
>> >> > > >> >>
>> >> > > >> >> On 10/4/06, Evgueni Brevnov <ev...@gmail.com>
>> >> wrote:
>> >> > > >> >> > Andrey,
>> >> > > >> >> >
>> >> > > >> >> > I see your points. I think both approaches have
>> >> advantages and
>> >> > > >> >> > disadvantages. I think it is quite hard to say which
>> >> approach is
>> >> > > >> >> > better until we play with one VM only. I still feel
>> >> like introducing
>> >> > > >> >> > one more dependence is better than spreading code
>> >> which deals with
>> >> > > >> >> > attachment among VM and TM. We really get stuck. OK,
>> >> just because I
>> >> > > >> >> > want to move forward I will do required changes to
>> remove
>> >> > > >> >> > vm_create_jthread from TM. I believe that will resolve
>> >> all our
>> >> > > >> >> > disagreements and the patch will be applied soon.
>> >> > > >> >> >
>> >> > > >> >> >
>> >> > > >> >> > Thanks
>> >> > > >> >> > Evgueni.
>> >> > > >> >> >
>> >> > > >> >> > On 10/4/06, Andrey Chernyshev
>> >> <a....@gmail.com> wrote:
>> >> > > >> >> > > On 10/3/06, Evgueni Brevnov
>> >> <ev...@gmail.com> wrote:
>> >> > > >> >> > > > On 10/3/06, Andrey Chernyshev
>> >> <a....@gmail.com> wrote:
>> >> > > >> >> > > > > On 10/2/06, Evgueni Brevnov
>> >> <ev...@gmail.com> wrote:
>> >> > > >> >> > > > > > Andrey,
>> >> > > >> >> > > > > >
>> >> > > >> >> > > > > > Just to be clear.... I agree with you it is
>> more
>> >> > > >> convenient if
>> >> > > >> >> > > > > > jthread_create takes JNIEnv instead of
>> JavaVM. It
>> >> > > >> reflects that
>> >> > > >> >> > > > > > current thread has been attached already. Do
>> >> you think it
>> >> > > >> >> makes sense
>> >> > > >> >> > > > > > to get rid of JNIEnv and use
>> >> jthread_get_JNI_env in that
>> >> > > >> case?
>> >> > > >> >> > > > >
>> >> > > >> >> > > > > The jthread_* layer is designed like if it were
>> >> a regular JNI
>> >> > > >> >> > > > > application which is meant to be called from the
>> >> Java code,
>> >> > > >> hence
>> >> > > >> >> > > > > every function on that layer receives JNIenv. We
>> >> can probably
>> >> > > >> >> get rid
>> >> > > >> >> > > > > of the JNEnv parameter for jthread_* functions,
>> >> assuming that
>> >> > > >> >> TM can
>> >> > > >> >> > > > > always extract JNIenv for the current thread
>> with
>> >> > > >> >> > > > > jthread_get_JNI_env().
>> >> > > >> >> > > > > My only concern would be the performance - once
>> >> the JNIenv is
>> >> > > >> >> already
>> >> > > >> >> > > > > known for the native part of the kernel classes
>> >> impl, it
>> >> > > >> must be
>> >> > > >> >> > > > > cheaper to pass JNIEnv to TM as an extra
>> >> parameter rather than
>> >> > > >> >> extract
>> >> > > >> >> > > > > it from the TLS again.
>> >> > > >> >> > > > > Other than that, I see no strong advantages in
>> >> keeping JNIEnv
>> >> > > >> >> parameter.
>> >> > > >> >> > > > >
>> >> > > >> >> > > > >
>> >> > > >> >> > > > > > Regarding jthread_attach. I still didn't get
>> >> your point....
>> >> > > >> >> Clarify it
>> >> > > >> >> > > > > > please if you think jhread_attach should be
>> >> modified.
>> >> > > >> >> > > > >
>> >> > > >> >> > > > > Sorry for being not clear: I think for
>> >> jthread_attach, we have
>> >> > > >> >> two options:
>> >> > > >> >> > > > > 1) Make JNIEnv input parameter - it must be new
>> >> JNIEnv that VM
>> >> > > >> >> > > > > pre-allocates for the new Java thread.
>> >> jthread_attach
>> >> > > >> would just
>> >> > > >> >> > > > > associate it with the current thread.
>> >> > > >> >> > > > >
>> >> > > >> >> > > > > 2) Obtain JNIEnv via vm_attach() callback. In
>> >> this case, if
>> >> > > >> >> > > > > vm_attach() callback implementation needs to
>> >> know for which
>> >> > > >> >> JavaVM new
>> >> > > >> >> > > > > JNIenv has to be allocated, then we'll need to
>> >> add JavaVM as
>> >> > > >> >> input
>> >> > > >> >> > > > > parameter for jthread_attach().
>> >> > > >> >> > > > > I think both options should be fine, (1) would
>> >> probably
>> >> > > >> keep TM
>> >> > > >> >> > > > > interface a bit lighter, though (2) may look
>> >> more closer to
>> >> > > >> >> the JNI
>> >> > > >> >> > > > > invocation API idea.
>> >> > > >> >> > > > > So I think adding JavaVM specifically for
>> >> jthread_attach
>> >> > > >> may make
>> >> > > >> >> > > > > sense given the explanation you provided
>> earlier.
>> >> > > >> >> > > > >
>> >> > > >> >> > > > > The concern I would have regarding the proposed
>> >> jthread_attach
>> >> > > >> >> > > > > implementation is a call to vm_create_jthread()
>> >> - this call
>> >> > > >> >> introduces
>> >> > > >> >> > > > > an extra dependency of TM on vmcore that I'd
>> >> prefer to be
>> >> > > >> >> avoided. In
>> >> > > >> >> > > > > the original version, jthread_attach() was
>> >> taking jthread
>> >> > > >> >> argument of
>> >> > > >> >> > > > > the already prepared j.l.Thread.
>> >> > > >> >> > > >
>> >> > > >> >> > > > I understand your concern. Unfortunately I don't
>> >> see what we
>> >> > > >> can do
>> >> > > >> >> > > > here. Let me explain. In the beginning you have an
>> >> unattached
>> >> > > >> >> native
>> >> > > >> >> > > > thread. To be able to call java code (which is
>> >> required for
>> >> > > >> >> > > > constructing j.l.Thread instance) the thread
>> >> should be attached
>> >> > > >> >> first.
>> >> > > >> >> > > > To be specific it should be attached to VM by
>> >> calling vm_attach
>> >> > > >> >> which
>> >> > > >> >> > > > will return a valid JNIEnv It is valid to use JNI
>> >> from that
>> >> > > >> moment.
>> >> > > >> >> > > > Obtained JNIEnv can be used to execute java code
>> >> and create
>> >> > > >> >> j.l.Thread
>> >> > > >> >> > > > instance. Since we do vm_attach in jthread_attach
>> >> we need to do
>> >> > > >> >> > > > vm_create_jthread inside jthread_atach as well.
>> >> > > >> >> > > > Of course it can be an alternative to do vm_attach
>> >> and
>> >> > > >> >> > > > vm_create_jthread outside of TM right before
>> >> jthread_attach.
>> >> > > >> >> Sure it
>> >> > > >> >> > > > will reduce one dependence between VM and TM. But
>> >> it seems like
>> >> > > >> >> > > > artificial action for me just because of
>> >> dependency....
>> >> > > >> >> > >
>> >> > > >> >> > > Why do you think it is artificial? I would rather
>> >> prefer not to
>> >> > > >> throw
>> >> > > >> >> > > vm_attach event from the jthread_attach() call at
>> >> all than to add
>> >> > > >> >> > > extra dependency. The idea of jthread layer is a
>> >> Java face to
>> >> > > >> >> > > hythread, it is meant to know either a little or
>> >> nothing about the
>> >> > > >> >> > > rest of VM. It may be logical to throw vm_attach
>> >> call from the
>> >> > > >> newly
>> >> > > >> >> > > created thread, because there is no other way to let
>> >> know VM
>> >> > > >> the new
>> >> > > >> >> > > thread is created. VM attach is a different case -
>> >> VM already
>> >> > > >> knows
>> >> > > >> >> > > about new Java thread at the time of the
>> >> AttachCurrentThread call.
>> >> > > >> >> > >
>> >> > > >> >> > > >
>> >> > > >> >> > > > > Do you think it makes sense to replace a single
>> >> jthread
>> >> > > >> >> parameter with
>> >> > > >> >> > > > > a variety of stuff (like thread group, name)? It
>> >> seems the
>> >> > > >> only
>> >> > > >> >> > > > > purpose of at these args is to be passed back to
>> >> VM for
>> >> > > >> >> > > > > vm_jthread_create(). I would suggest to change
>> >> this and try
>> >> > > >> doing
>> >> > > >> >> > > > > either of:
>> >> > > >> >> > > > > 1) Make signature of jthread_attach with 3 args,
>> >> JavaVM,
>> >> > > >> >> jthread and the daemon.
>> >> > > >> >> > > > Why do you want to pass daemon to TM but thread's
>> >> name and
>> >> > > >> >> group. Just
>> >> > > >> >> > > > because current TM doesn't need such information?
>> >> What if it is
>> >> > > >> >> > > > required to get thread name later? Say by
>> introducing
>> >> > > >> >> > >
>> >> > > >> >> > > I imagine you need a daemon attribute since the TM
>> >> is still
>> >> > > >> managing
>> >> > > >> >> > > the thread daemonality. TM is not managing thread
>> >> name and group -
>> >> > > >> >> > > they are all kept on the Java level, hence passing
>> >> them may be
>> >> > > >> >> > > excessive.
>> >> > > >> >> > >
>> >> > > >> >> > > > jthread_get_name... What will you do in that case?
>> >> Let me
>> >> > > >> guess you
>> >> > > >> >> > > > will call j.l.Thread.getName. Right. Ok! In that
>> >> case I see no
>> >> > > >> >> > > > problems to call j.l.Thread.isDaemon. Do you
>> >> agree? So it
>> >> > > >> doesn't
>> >> > > >> >> > >
>> >> > > >> >> > > As I suggested earlier, the best way to handle
>> >> daemonality would
>> >> > > >> >> > > probably be in pure Java - in j.l.Thread (or
>> >> > > >> j.l.VMThreadManager) or
>> >> > > >> >> > > whatever. You already lifted it up to the jthread
>> >> level, but
>> >> > > >> what if
>> >> > > >> >> > > we can go a little bit higher...
>> >> > > >> >> > >
>> >> > > >> >> > > > seems to be a good design to pass only part of the
>> >> > > >> information to
>> >> > > >> >> > > > jthread_atach. Lets look at the signature of
>> >> > > >> >> AttachCurrentThread. It
>> >> > > >> >> > > > takes exactly these three parameters (daemon,
>> >> name, group)
>> >> > > >> >> passed as a
>> >> > > >> >> > > > structure. I was thinking about having exactly the
>> >> same
>> >> > > >> >> structure as
>> >> > > >> >> > > > third parameter of jthread_attach but it occured
>> >> to be more
>> >> > > >> >> convinient
>> >> > > >> >> > > > to pass them seperatly. Although I don't see
>> >> strong reasons
>> >> > > >> against
>> >> > > >> >> > > > having a structure a third parameter.
>> >> > > >> >> > >
>> >> > > >> >> > > I see. Acually, I would love to keep the
>> >> jthread_attach func-ty at
>> >> > > >> >> the
>> >> > > >> >> > > minimum level which will be needed to handle the
>> >> only data that TM
>> >> > > >> >> > > should be aware of. We need a formal boundary
>> >> between jthread
>> >> > > >> layer
>> >> > > >> >> > > and vmcore (otherwise jthread won't have a much of
>> >> sense, one may
>> >> > > >> >> > > consider it just as a convenience set of functions
>> >> in vmcore which
>> >> > > >> >> are
>> >> > > >> >> > > doing something with threading).
>> >> > > >> >> > >
>> >> > > >> >> > > >
>> >> > > >> >> > > > > 2) Move the implementation of vm_create_jtrhead
>> >> () to
>> >> > > >> >> > > > > thread_java_basic.c - could it be written in
>> >> pure JNI without
>> >> > > >> >> using
>> >> > > >> >> > > > > internal VM API like class_alloc_new_object()?
>> >> > > >> >> > > >
>> >> > > >> >> > > > Yes, this can be done but it doesn't fix the
>> >> problem. You still
>> >> > > >> >> need
>> >> > > >> >> > > > to know about internal constructor of j.l.Thread
>> >> > > >> >> > >
>> >> > > >> >> > > That's bad. Given what you said, now it seems that
>> >> the most
>> >> > > >> >> preferable
>> >> > > >> >> > > sequence for AttachCurrentThread impl still would be
>> >> like:
>> >> > > >> >> > > JNIEnv = vm_attach();
>> >> > > >> >> > > jthread = create_jthread(JNIenv)
>> >> > > >> >> > > jthread_attach(JNIEnv, jthread) // stores JNIEnv and
>> >> Hythread into
>> >> > > >> >> > > TLS, doesn't call vm_attach any longer.
>> >> > > >> >> > > - this is almost what we had from the beginning...
>> >> > > >> >> > >
>> >> > > >> >> > > Thanks,
>> >> > > >> >> > > Andrey.
>> >> > > >> >> > >
>> >> > > >> >> > > >
>> >> > > >> >> > > >
>> >> > > >> >> > > > Thanks
>> >> > > >> >> > > > Evgueni
>> >> > > >> >> > > > >
>> >> > > >> >> > > > >
>> >> > > >> >> > > > > Thanks,
>> >> > > >> >> > > > > Andrey.
>> >> > > >> >> > > > >
>> >> > > >> >> > > > > >
>> >> > > >> >> > > > > > Thank you
>> >> > > >> >> > > > > > Evgueni
>> >> > > >> >> > > > > >
>> >> > > >> >> > > > > > On 10/2/06, Evgueni Brevnov
>> >> <ev...@gmail.com>
>> >> > > >> wrote:
>> >> > > >> >> > > > > > > On 9/29/06, Andrey Chernyshev
>> >> <a....@gmail.com>
>> >> > > >> >> wrote:
>> >> > > >> >> > > > > > > > On 9/29/06, Evgueni Brevnov
>> >> <ev...@gmail.com>
>> >> > > >> >> wrote:
>> >> > > >> >> > > > > > > > > Artem,
>> >> > > >> >> > > > > > > > >
>> >> > > >> >> > > > > > > > > Thank you for your feedback.... find my
>> >> inlined.....
>> >> > > >> >> > > > > > > > >
>> >> > > >> >> > > > > > > > > On 9/29/06, Artem Aliev
>> >> <ar...@gmail.com> wrote:
>> >> > > >> >> > > > > > > > > > Evgueni,
>> >> > > >> >> > > > > > > > > >
>> >> > > >> >> > > > > > > > > > I got most of your changes, but still
>> >> disagree
>> >> > > >> with all
>> >> > > >> >> > > > > > > > > > hythread/jthread interface changes.
>> >> Could leave
>> >> > > >> >> interface unchanged.
>> >> > > >> >> > > > > > > > > > See following possible solutions, that
>> >> could solve
>> >> > > >> >> the same problems
>> >> > > >> >> > > > > > > > > > without interface changes.
>> >> > > >> >> > > > > > > > > >
>> >> > > >> >> > > > > > > > > >
>> >> > > >> >> > > > > > > > > > 1) daemon attribute is a java
>> >> specific. (Andrey
>> >> > > >> >> mentioned this already).
>> >> > > >> >> > > > > > > > > > Could you please move it back. to
>> >> the jthread
>> >> > > >> >> layer. It is better
>> >> > > >> >> > > > > > > > > > to rename
>> >> > > >> >> > > > > > > > > >
>> >> hythread_wait_for_all_nondaemon_threads() to
>> >> > > >> >> > > > > > > > > >
>> jthread_wait_for_all_nondaemon_threads().
>> >> > > >> >> > > > > > > > > Ok, I see no problems to move "daemon"
>> >> to java layer.
>> >> > > >> >> In that case:
>> >> > > >> >> > > > > > > > > 1) I will move
>> >> > > >> >> hythread_wait_for_all_nondaemon_threads() from
>> >> > > >> >> > > > > > > > > thread_init.c to one which implements
>> >> java layer.
>> >> > > >> >> > > > > > > > > 2) I will move daemon field from
>> >> HyThread structure.
>> >> > > >> >> > > > > > > > >
>> >> > > >> >> > > > > > > > > Agree?
>> >> > > >> >> > > > > > > >
>> >> > > >> >> > > > > > > > Sounds good to me.
>> >> > > >> >> > > > > > >
>> >> > > >> >> > > > > > > OK, will do that.
>> >> > > >> >> > > > > > >
>> >> > > >> >> > > > > > > >
>> >> > > >> >> > > > > > > >
>> >> > > >> >> > > > > > > > >
>> >> > > >> >> > > > > > > > > >
>> >> > > >> >> > > > > > > > > > 2) JavaVM could be retrieved from
>> >> JNIEnv by
>> >> > > >> >> jni_get_java_vm(). So
>> >> > > >> >> > > > > > > > > > let the jthread_create() and others to
>> >> use JNIEnv
>> >> > > >> >> (that is passed from
>> >> > > >> >> > > > > > > > > > java native method).
>> >> > > >> >> > > > > > > > > > The vm_attach could get old JNI env
>> >> and create new
>> >> > > >> >> one for the new thread.
>> >> > > >> >> > > > > > > > > > The first JNIEnv is created in
>> >> CreateVM call and
>> >> > > >> >> could be passed to
>> >> > > >> >> > > > > > > > > > the first thread at startup.
>> >> > > >> >> > > > > > > > > No, no, no. I completely disagree with
>> >> that!!! Why do
>> >> > > >> >> you like JNIEnv
>> >> > > >> >> > > > > > > > > but JavaVM. Why do you think that
>> >> passing JavaVM
>> >> > > >> >> instead of JNIEnv
>> >> > > >> >> > > > > > > > > makes TM less modular? I don't see any
>> >> difference
>> >> > > >> >> here.... It seems
>> >> > > >> >> > > > > > > > > for me like a big big hack to grab
>> >> JNIEnv from another
>> >> > > >> >> thread and pass
>> >> > > >> >> > > > > > > > > it to jthread_attach to perform
>> >> operations in the
>> >> > > >> >> current thread.
>> >> > > >> >> > > > > > > >
>> >> > > >> >> > > > > > > > TM needs to know JNIEnv, mainly for
>> >> managing the
>> >> > > >> >> references to
>> >> > > >> >> > > > > > > > objects, throwing exceptions and calling
>> >> run() method of
>> >> > > >> >> a new thread.
>> >> > > >> >> > > > > > > > JNI spec proposes that JNIEnv is valid
>> >> within the given
>> >> > > >> >> thread, this
>> >> > > >> >> > > > > > > > is why TM holds the JNIEnv pointer at the
>> >> moment. This
>> >> > > >> >> is why TM likes
>> >> > > >> >> > > > > > > > the JNIEnv.
>> >> > > >> >> > > > > > > >
>> >> > > >> >> > > > > > > > Having the JNIEnv, one is able to get
>> >> JavaVM but not
>> >> > > >> >> vise versa. This
>> >> > > >> >> > > > > > > > is why TM doesn't like the JavaVM :)
>> >> > > >> >> > > > > > > I see your point. Only one note this is true
>> >> for already
>> >> > > >> >> attached threads...
>> >> > > >> >> > > > > > >
>> >> > > >> >> > > > > > > >
>> >> > > >> >> > > > > > > > I agree with you that there is a design
>> >> flaw that the
>> >> > > >> >> JNIEnv is copied
>> >> > > >> >> > > > > > > > from the parent thread to a child thread
>> >> during thread
>> >> > > >> >> creation. I
>> >> > > >> >> > > > > > > > think it could be resolved via vm_attach()
>> >> hook - with
>> >> > > >> >> this event, VM
>> >> > > >> >> > > > > > > > might tell the TM what the JNIEnv pointer
>> >> for new thread
>> >> > > >> >> should be. I
>> >> > > >> >> > > > > > > > think you did that by extending the
>> >> vm_attach() call
>> >> > > >> >> with the JNIEnv**
>> >> > > >> >> > > > > > > > argument.
>> >> > > >> >> > > > > > > >
>> >> > > >> >> > > > > > > > What is not completely clear is, why do
>> >> you have to pass
>> >> > > >> >> the JavaVM
>> >> > > >> >> > > > > > > > forth and back, once from VM to TM, and
>> >> then back from
>> >> > > >> >> TM to VM again?
>> >> > > >> >> > > > > > > >
>> >> > > >> >> > > > > > > > If you need to know in jthread_attach,
>> >> which particular
>> >> > > >> >> VM vm_attach()
>> >> > > >> >> > > > > > > > event is coming from, you could have
>> >> vm_attach like
>> >> > > >> >> > > > > > > > vm_attach(JNIEnv* currentThreadEnv,
>> JNIEnv**
>> >> > > >> >> newThreadEnv).
>> >> > > >> >> > > > > > > I'm a little bit confused.....Current thread
>> >> hasn't been
>> >> > > >> >> attached yet.
>> >> > > >> >> > > > > > > So there is no JNIEnv for it yet. How it can
>> >> be passed as
>> >> > > >> >> the first
>> >> > > >> >> > > > > > > parameter to vm_attach()?
>> >> > > >> >> > > > > > >
>> >> > > >> >> > > > > > > > Then you will be always able to get the
>> >> JavaVM from the
>> >> > > >> >> JNIEnv.
>> >> > > >> >> > > > > > > > The only difference is that you are
>> >> currently doing
>> >> > > >> >> JNIEnv->JavaVM
>> >> > > >> >> > > > > > > > conversion in the VMThreadManager, but why
>> >> can't you
>> >> > > >> >> just do this in
>> >> > > >> >> > > > > > > > vm_attach() without changing the interface
>> >> of the TM?
>> >> > > >> >> > > > > > > > So far JavaVM really looks like an extra
>> >> knowledge that
>> >> > > >> >> TM doesn't
>> >> > > >> >> > > > > > > > have to be aware of.
>> >> > > >> >> > > > > > > >
>> >> > > >> >> > > > > > > > > Moreover there is no JNIEnv when main
>> >> thread attaches
>> >> > > >> >> to VM. So we
>> >> > > >> >> > > > > > > > > should either keep it as is or change
>> >> original design
>> >> > > >> >> of TM and attach
>> >> > > >> >> > > > > > > > > thread to VM before attaching it to TM.
>> >> In that case
>> >> > > >> >> we will have
>> >> > > >> >> > > > > > > > > valid JNIEnv which can be passed to
>> >> jthread_atatch. We
>> >> > > >> >> need to think
>> >> > > >> >> > > > > > > > > over it twice before changing
>> something....
>> >> > > >> >> > > > > > > >
>> >> > > >> >> > > > > > > > Right. For jthread_attach, JNIenv needs to
>> >> be changed
>> >> > > >> >> from being input
>> >> > > >> >> > > > > > > > parameter to being the output parameter.
>> >> The way how
>> >> > > >> >> JNIenv is
>> >> > > >> >> > > > > > > > obtained by TM should be vm_attach()
>> event.
>> >> > > >> >> > > > > > > OK, JNIEnv is output parameter. And it
>> >> obtained by
>> >> > > >> >> vm_attach(). This
>> >> > > >> >> > > > > > > is exactly like I do in the patch. What I
>> >> don't understand
>> >> > > >> >> is how
>> >> > > >> >> > > > > > > jthread_attach knows to which VM the thread
>> >> should be
>> >> > > >> >> attached? Do you
>> >> > > >> >> > > > > > > suggest calling vm_attach first to create
>> >> JNIEnv it pass
>> >> > > >> >> it to
>> >> > > >> >> > > > > > > jthread_attach?
>> >> > > >> >> > > > > > >
>> >> > > >> >> > > > > > > >
>> >> > > >> >> > > > > > > > >
>> >> > > >> >> > > > > > > > >
>> >> > > >> >> > > > > > > > >
>> >> > > >> >> > > > > > > > > >
>> >> > > >> >> > > > > > > > > >
>> >> > > >> >> > > > > > > > > > 4) Original classlib hythread do
>> not use
>> >> > > >> >> hythread_library_t in arguments,
>> >> > > >> >> > > > > > > > > > It uses following code:
>> >> > > >> >> > > > > > > > > >
>> >> > > >> >> > > > > > > > > > hythread_library_t lib = GLOBAL_DATA
>> >> > > >> >> (default_library);
>> >> > > >> >> > > > > > > > > > or
>> >> > > >> >> > > > > > > > > > hythread_library_t library = thread-
>> >> >library;
>> >> > > >> >> > > > > > > > > >
>> >> > > >> >> > > > > > > > > > So could you please use the same
>> >> mechanism and
>> >> > > >> >> remove hythread_*_ex >functions.
>> >> > > >> >> > > > > > > > > Let's see if classlib's hythread needs
>> >> changing first.
>> >> > > >> >> It seems for me
>> >> > > >> >> > > > > > > > > such code prevents us from having
>> multi VM.
>> >> > > >> >> > > > > > > > >
>> >> > > >> >> > > > > > > > > >
>> >> > > >> >> > > > > > > > > > 5. You introduce more then one jni
>> >> env, but still
>> >> > > >> >> use global variable for it.
>> >> > > >> >> > > > > > > > > > So all changes like following:
>> >> > > >> >> > > > > > > > > > - JNIEnv *jenv = (JNIEnv*)
>> >> jni_native_intf;
>> >> > > >> >> > > > > > > > > > + JNIEnv *jenv = jni_native_intf;
>> >> > > >> >> > > > > > > > > >
>> >> > > >> >> > > > > > > > > > should be like:
>> >> > > >> >> > > > > > > > > > - JNIEnv *jenv = (JNIEnv*)
>> >> jni_native_intf;
>> >> > > >> >> > > > > > > > > > + JNIEnv *jenv = get_jni_env
>> >> (jthread_self());
>> >> > > >> >> > > > > > > > >
>> >> > > >> >> > > > > > > > > Ok, I see. I agree that global
>> >> jni_native_intf should
>> >> > > >> >> not be used.
>> >> > > >> >> > > > > > > > > There was simple reason why I altered
>> >> such lines.
>> >> > > >> >> Because I changed
>> >> > > >> >> > > > > > > > > the type of jni_native_intf and no
>> >> casting operator
>> >> > > >> >> is needed now. To
>> >> > > >> >> > > > > > > > > be honest I think get_jni_env
>> >> (jthread_self()) can be
>> >> > > >> >> good as temporary
>> >> > > >> >> > > > > > > > > solution only. Lets wait for design of
>> >> multi VM and
>> >> > > >> >> fix it according
>> >> > > >> >> > > > > > > > > to it.
>> >> > > >> >> > > > > > > >
>> >> > > >> >> > > > > > > > While we are in JNI code, we always have
>> >> the JNIenv (at
>> >> > > >> >> least
>> >> > > >> >> > > > > > > > initially it comes from Java code). If we
>> >> consider VM
>> >> > > >> >> code as if it
>> >> > > >> >> > > > > > > > was a JNI application, then it seems like
>> >> we should be
>> >> > > >> >> just passing
>> >> > > >> >> > > > > > > > JNIEnv as a parameter to all functions in
>> >> VM. Or, we can
>> >> > > >> >> be taking it
>> >> > > >> >> > > > > > > > from TLS (via jthread_self()), depending
>> >> on which way is
>> >> > > >> >> faster...
>> >> > > >> >> > > > > > > Agree.
>> >> > > >> >> > > > > > >
>> >> > > >> >> > > > > > > >
>> >> > > >> >> > > > > > > > >
>> >> > > >> >> > > > > > > > > >
>> >> > > >> >> > > > > > > > > > 6). And small remarks:
>> >> > > >> >> > > > > > > > > > +jint vm_init1(JavaVM_Internal *
>> java_vm,
>> >> > > >> >> JavaVMInitArgs * vm_arguments);
>> >> > > >> >> > > > > > > > > > +jint vm_init2(JNIEnv_Internal *
>> >> jni_env);
>> >> > > >> >> > > > > > > > > > Could you make names more meaningful,
>> >> then 1,2,3...?
>> >> > > >> >> > > > > > > > > Ok, will do that.
>> >> > > >> >> > > > > > > > >
>> >> > > >> >> > > > > > > > > >
>> >> > > >> >> > > > > > > > > > class VM_thread {
>> >> > > >> >> > > > > > > > > > ...
>> >> > > >> >> > > > > > > > > > + JNIEnv_Internal * jni_env;
>> >> > > >> >> > > > > > > > > > The jthread already has the jni_env
>> >> pointer, you do
>> >> > > >> >> not need to
>> >> > > >> >> > > > > > > > > > duplicate it here.
>> >> > > >> >> > > > > > > > > > forexample by using
>> >> > > >> >> jthread_get_JNI_env(jthread_self());
>> >> > > >> >> > > > > > > > >
>> >> > > >> >> > > > > > > > > Yes I know. I don't see any problems
>> >> here. Some times
>> >> > > >> >> it is much more
>> >> > > >> >> > > > > > > > > convenient to get JNIEnv from VM_thread
>> >> structure (and
>> >> > > >> >> faster) instead
>> >> > > >> >> > > > > > > > > of doing jthread_get_JNI_env
>> (jthread_self
>> >> ()). So I
>> >> > > >> >> need strong
>> >> > > >> >> > > > > > > > > arguments for removing it. Again it
>> >> seems that should
>> >> > > >> >> be addressed in
>> >> > > >> >> > > > > > > > > design of multi VM. So lets forget about
>> >> it for a
>> >> > > >> >> while...
>> >> > > >> >> > > > > > > >
>> >> > > >> >> > > > > > > > I think that the data duplication would
>> >> always serve as
>> >> > > >> >> a potential
>> >> > > >> >> > > > > > > > source of errors - while updating one copy
>> >> of object,
>> >> > > >> >> you may forget
>> >> > > >> >> > > > > > > > to update the other, often resulting into
>> >> a strange
>> >> > > >> >> behavior of the
>> >> > > >> >> > > > > > > > whole application. Let's see what are the
>> >> specific
>> >> > > >> >> performance
>> >> > > >> >> > > > > > > > concerns that have to be addressed. To get
>> >> VM_thread
>> >> > > >> >> structure, you
>> >> > > >> >> > > > > > > > would eventually go to the TLS, just like
>> >> > > >> >> > > > > > > > jthread_get_JNI_env(jthread_self()
>> would do.
>> >> > > >> >> > > > > > > If there is already VM_thread structure for
>> >> some reasons
>> >> > > >> >> then there
>> >> > > >> >> > > > > > > will be no extra access to TLS. It is
>> >> definitely much
>> >> > > >> more in
>> >> > > >> >> > > > > > > jthread_get_JNI_env(jthread_self() than just
>> >> one TLS
>> >> > > >> >> access and one
>> >> > > >> >> > > > > > > dereferncing. I don't think it is a really
>> >> big problem
>> >> > > >> >> now. Do you
>> >> > > >> >> > > > > > > agree to look at this later. I guess
>> multi VM
>> >> > > >> >> implementation will
>> >> > > >> >> > > > > > > alter it in any case.
>> >> > > >> >> > > > > > >
>> >> > > >> >> > > > > > > Thanks
>> >> > > >> >> > > > > > > Evgueni
>> >> > > >> >> > > > > > >
>> >> > > >> >> > > > > > > >
>> >> > > >> >> > > > > > > > Thanks,
>> >> > > >> >> > > > > > > > Andrey.
>> >> > > >> >> > > > > > > >
>> >> > > >> >> > > > > > > > >
>> >> > > >> >> > > > > > > > > Evgueni
>> >> > > >> >> > > > > > > > > >
>> >> > > >> >> > > > > > > > > > Thanks
>> >> > > >> >> > > > > > > > > > Artem
>> >> > > >> >> > > > > > > > > >
>> >> > > >> >> > > > > > > > > > On 9/28/06, Evgueni Brevnov
>> >> > > >> >> <ev...@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.
>> >> > > >> >> > > > > > > > > > >
>> >> > > >> >> > > > > > > > > > > Thanks
>> >> > > >> >> > > > > > > > > > > Evgueni
>> >> > > >> >> > > > > > > > > > >
>> >> > > >> >> > > > > > > > > > > On 9/28/06, Geir Magnusson Jr.
>> >> <ge...@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
>> >> > > >> >> <we...@gmail.com> wrote:
>> >> > > >> >> > > > > > > > > > > > >> On 9/26/06, Evgueni Brevnov
>> >> > > >> >> <ev...@gmail.com> wrote:
>> >> > > >> >> > > > > > > > > > > > >> >
>> >> > > >> >> > > > > > > > > > > > >> > On 9/27/06, Andrey Chernyshev
>> >> > > >> >> <a....@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
>> >> > > >> >> > > > > > > > > > >
>> >> > > >> >> > > > > > > > > > >
>> >> > > >> >> > > > > > > > > >
>> >> > > >> >> > > > > > > > > >
>> >> > > >> >>
>> >>
>> ---------------------------------------------------------------------
>> >> > > >> >> > > > > > > > > > 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
>> >> > > >> >> > > > > > > > >
>> >> > > >> >> > > > > > > > >
>> >> > > >> >> > > > > > > >
>> >> > > >> >> > > > > > > >
>> >> > > >> >> > > > > > > > --
>> >> > > >> >> > > > > > > > Andrey Chernyshev
>> >> > > >> >> > > > > > > > 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
>> >> > > >> >> > > > > >
>> >> > > >> >> > > > > >
>> >> > > >> >> > > > >
>> >> > > >> >> > > > >
>> >> > > >> >> > > > > --
>> >> > > >> >> > > > > Andrey Chernyshev
>> >> > > >> >> > > > > 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
>> >> > > >> >> > > >
>> >> > > >> >> > > >
>> >> > > >> >> > >
>> >> > > >> >> > >
>> >> > > >> >> > > --
>> >> > > >> >> > > Andrey Chernyshev
>> >> > > >> >> > > 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
>> >> > > >>
>> >> > > >>
>> >> > > >
>> >> > > >
>> >>
>> ---------------------------------------------------------------------
>> >> > > > 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
>> >
>>
>>
>> ---------------------------------------------------------------------
>> 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
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
Posted by Evgueni Brevnov <ev...@gmail.com>.
I put debug printing into test_ti_instrum.c and attached it to JIRA.
Could you run it on your machine and send me console output.
Evgueni
On 10/9/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> I keep getting a failure when running the tests -
>
> test_jthread_get_all-threads failling the assertion at
> test_ti_instrum.c:80
>
> geir
>
> On Oct 8, 2006, at 7:19 AM, Evgueni Brevnov wrote:
>
> > While running cunit on Linux it turned out one test case fails some
> > time. The fix is in tests.final.2.patch.
> >
> > So the last versions to be committed:
> > invocation_api.final.patch
> > build.final.2.patch
> > tests.final.2.patch
> >
> > Evgueni
> >
> >
> > On 10/8/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> >> I mahaged to resolve the problem on Linux.... will update
> >> build.final.patch with build.final.2.patch in a while
> >>
> >> On 10/8/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> >> > Hi,
> >> >
> >> > Oh! Ooh! I did that..... I passed cunit, somke, kernel tests on
> >> > Windows and smoke, kernel tests on Linux. Unfortunately I failed to
> >> > link cunit tests on Linux so far. So I disabled cunit on Linux
> >> until
> >> > the problem is solved. I believe it is acceptable as short term
> >> > solution. I found several problems in cunit tests. I will come
> >> up with
> >> > my findings later (not today).
> >> >
> >> > Use latest patches from HARMONY-1582. They are marked as final.
> >> There
> >> > are three patches. One for build module, one for cunit tests and
> >> one
> >> > for VM itself.
> >> >
> >> > Thanks
> >> > Evgueni
> >> >
> >> >
> >> > On 10/6/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> >> > > Nooooooo! LOL
> >> > >
> >> > > I'm here waiting - This will unblock a whole bunch of things :)
> >> > >
> >> > > Thanks for the effort
> >> > >
> >> > > Evgueni Brevnov wrote:
> >> > > > Geir,
> >> > > >
> >> > > > That's terrible. We have power outage....servers are down. I
> >> can't
> >> > > > send the patches now.... will do it tomorrow
> >> > > >
> >> > > > Evgueni
> >> > > > On 10/5/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> >> > > >> woo hoo! here we go...
> >> > > >>
> >> > > >>
> >> > > >> Andrey Chernyshev wrote:
> >> > > >> > Hi Evgueni,
> >> > > >> >
> >> > > >> > On 10/4/06, Evgueni Brevnov <ev...@gmail.com>
> >> wrote:
> >> > > >> >> Hi All,
> >> > > >> >>
> >> > > >> >> I have attached updated patch to the JIRA. It should
> >> resolve remain
> >> > > >> >> concerns. Andrey, could you give a green light now?
> >> > > >> >
> >> > > >> > Thanks for updating the patch! I agree it it can be
> >> committed, at
> >> > > >> > least signatures look good. 5 revisions seem like more
> >> than enough :).
> >> > > >> > Anyways, I think the remaining issues can be resolved
> >> with additional
> >> > > >> > patches. Thanks again for the good work and your patience.
> >> > > >> >
> >> > > >> > Thanks,
> >> > > >> > Andrey.
> >> > > >> >
> >> > > >> >>
> >> > > >> >> Thanks
> >> > > >> >> Evgueni
> >> > > >> >>
> >> > > >> >> On 10/4/06, Evgueni Brevnov <ev...@gmail.com>
> >> wrote:
> >> > > >> >> > Andrey,
> >> > > >> >> >
> >> > > >> >> > I see your points. I think both approaches have
> >> advantages and
> >> > > >> >> > disadvantages. I think it is quite hard to say which
> >> approach is
> >> > > >> >> > better until we play with one VM only. I still feel
> >> like introducing
> >> > > >> >> > one more dependence is better than spreading code
> >> which deals with
> >> > > >> >> > attachment among VM and TM. We really get stuck. OK,
> >> just because I
> >> > > >> >> > want to move forward I will do required changes to remove
> >> > > >> >> > vm_create_jthread from TM. I believe that will resolve
> >> all our
> >> > > >> >> > disagreements and the patch will be applied soon.
> >> > > >> >> >
> >> > > >> >> >
> >> > > >> >> > Thanks
> >> > > >> >> > Evgueni.
> >> > > >> >> >
> >> > > >> >> > On 10/4/06, Andrey Chernyshev
> >> <a....@gmail.com> wrote:
> >> > > >> >> > > On 10/3/06, Evgueni Brevnov
> >> <ev...@gmail.com> wrote:
> >> > > >> >> > > > On 10/3/06, Andrey Chernyshev
> >> <a....@gmail.com> wrote:
> >> > > >> >> > > > > On 10/2/06, Evgueni Brevnov
> >> <ev...@gmail.com> wrote:
> >> > > >> >> > > > > > Andrey,
> >> > > >> >> > > > > >
> >> > > >> >> > > > > > Just to be clear.... I agree with you it is more
> >> > > >> convenient if
> >> > > >> >> > > > > > jthread_create takes JNIEnv instead of JavaVM. It
> >> > > >> reflects that
> >> > > >> >> > > > > > current thread has been attached already. Do
> >> you think it
> >> > > >> >> makes sense
> >> > > >> >> > > > > > to get rid of JNIEnv and use
> >> jthread_get_JNI_env in that
> >> > > >> case?
> >> > > >> >> > > > >
> >> > > >> >> > > > > The jthread_* layer is designed like if it were
> >> a regular JNI
> >> > > >> >> > > > > application which is meant to be called from the
> >> Java code,
> >> > > >> hence
> >> > > >> >> > > > > every function on that layer receives JNIenv. We
> >> can probably
> >> > > >> >> get rid
> >> > > >> >> > > > > of the JNEnv parameter for jthread_* functions,
> >> assuming that
> >> > > >> >> TM can
> >> > > >> >> > > > > always extract JNIenv for the current thread with
> >> > > >> >> > > > > jthread_get_JNI_env().
> >> > > >> >> > > > > My only concern would be the performance - once
> >> the JNIenv is
> >> > > >> >> already
> >> > > >> >> > > > > known for the native part of the kernel classes
> >> impl, it
> >> > > >> must be
> >> > > >> >> > > > > cheaper to pass JNIEnv to TM as an extra
> >> parameter rather than
> >> > > >> >> extract
> >> > > >> >> > > > > it from the TLS again.
> >> > > >> >> > > > > Other than that, I see no strong advantages in
> >> keeping JNIEnv
> >> > > >> >> parameter.
> >> > > >> >> > > > >
> >> > > >> >> > > > >
> >> > > >> >> > > > > > Regarding jthread_attach. I still didn't get
> >> your point....
> >> > > >> >> Clarify it
> >> > > >> >> > > > > > please if you think jhread_attach should be
> >> modified.
> >> > > >> >> > > > >
> >> > > >> >> > > > > Sorry for being not clear: I think for
> >> jthread_attach, we have
> >> > > >> >> two options:
> >> > > >> >> > > > > 1) Make JNIEnv input parameter - it must be new
> >> JNIEnv that VM
> >> > > >> >> > > > > pre-allocates for the new Java thread.
> >> jthread_attach
> >> > > >> would just
> >> > > >> >> > > > > associate it with the current thread.
> >> > > >> >> > > > >
> >> > > >> >> > > > > 2) Obtain JNIEnv via vm_attach() callback. In
> >> this case, if
> >> > > >> >> > > > > vm_attach() callback implementation needs to
> >> know for which
> >> > > >> >> JavaVM new
> >> > > >> >> > > > > JNIenv has to be allocated, then we'll need to
> >> add JavaVM as
> >> > > >> >> input
> >> > > >> >> > > > > parameter for jthread_attach().
> >> > > >> >> > > > > I think both options should be fine, (1) would
> >> probably
> >> > > >> keep TM
> >> > > >> >> > > > > interface a bit lighter, though (2) may look
> >> more closer to
> >> > > >> >> the JNI
> >> > > >> >> > > > > invocation API idea.
> >> > > >> >> > > > > So I think adding JavaVM specifically for
> >> jthread_attach
> >> > > >> may make
> >> > > >> >> > > > > sense given the explanation you provided earlier.
> >> > > >> >> > > > >
> >> > > >> >> > > > > The concern I would have regarding the proposed
> >> jthread_attach
> >> > > >> >> > > > > implementation is a call to vm_create_jthread()
> >> - this call
> >> > > >> >> introduces
> >> > > >> >> > > > > an extra dependency of TM on vmcore that I'd
> >> prefer to be
> >> > > >> >> avoided. In
> >> > > >> >> > > > > the original version, jthread_attach() was
> >> taking jthread
> >> > > >> >> argument of
> >> > > >> >> > > > > the already prepared j.l.Thread.
> >> > > >> >> > > >
> >> > > >> >> > > > I understand your concern. Unfortunately I don't
> >> see what we
> >> > > >> can do
> >> > > >> >> > > > here. Let me explain. In the beginning you have an
> >> unattached
> >> > > >> >> native
> >> > > >> >> > > > thread. To be able to call java code (which is
> >> required for
> >> > > >> >> > > > constructing j.l.Thread instance) the thread
> >> should be attached
> >> > > >> >> first.
> >> > > >> >> > > > To be specific it should be attached to VM by
> >> calling vm_attach
> >> > > >> >> which
> >> > > >> >> > > > will return a valid JNIEnv It is valid to use JNI
> >> from that
> >> > > >> moment.
> >> > > >> >> > > > Obtained JNIEnv can be used to execute java code
> >> and create
> >> > > >> >> j.l.Thread
> >> > > >> >> > > > instance. Since we do vm_attach in jthread_attach
> >> we need to do
> >> > > >> >> > > > vm_create_jthread inside jthread_atach as well.
> >> > > >> >> > > > Of course it can be an alternative to do vm_attach
> >> and
> >> > > >> >> > > > vm_create_jthread outside of TM right before
> >> jthread_attach.
> >> > > >> >> Sure it
> >> > > >> >> > > > will reduce one dependence between VM and TM. But
> >> it seems like
> >> > > >> >> > > > artificial action for me just because of
> >> dependency....
> >> > > >> >> > >
> >> > > >> >> > > Why do you think it is artificial? I would rather
> >> prefer not to
> >> > > >> throw
> >> > > >> >> > > vm_attach event from the jthread_attach() call at
> >> all than to add
> >> > > >> >> > > extra dependency. The idea of jthread layer is a
> >> Java face to
> >> > > >> >> > > hythread, it is meant to know either a little or
> >> nothing about the
> >> > > >> >> > > rest of VM. It may be logical to throw vm_attach
> >> call from the
> >> > > >> newly
> >> > > >> >> > > created thread, because there is no other way to let
> >> know VM
> >> > > >> the new
> >> > > >> >> > > thread is created. VM attach is a different case -
> >> VM already
> >> > > >> knows
> >> > > >> >> > > about new Java thread at the time of the
> >> AttachCurrentThread call.
> >> > > >> >> > >
> >> > > >> >> > > >
> >> > > >> >> > > > > Do you think it makes sense to replace a single
> >> jthread
> >> > > >> >> parameter with
> >> > > >> >> > > > > a variety of stuff (like thread group, name)? It
> >> seems the
> >> > > >> only
> >> > > >> >> > > > > purpose of at these args is to be passed back to
> >> VM for
> >> > > >> >> > > > > vm_jthread_create(). I would suggest to change
> >> this and try
> >> > > >> doing
> >> > > >> >> > > > > either of:
> >> > > >> >> > > > > 1) Make signature of jthread_attach with 3 args,
> >> JavaVM,
> >> > > >> >> jthread and the daemon.
> >> > > >> >> > > > Why do you want to pass daemon to TM but thread's
> >> name and
> >> > > >> >> group. Just
> >> > > >> >> > > > because current TM doesn't need such information?
> >> What if it is
> >> > > >> >> > > > required to get thread name later? Say by introducing
> >> > > >> >> > >
> >> > > >> >> > > I imagine you need a daemon attribute since the TM
> >> is still
> >> > > >> managing
> >> > > >> >> > > the thread daemonality. TM is not managing thread
> >> name and group -
> >> > > >> >> > > they are all kept on the Java level, hence passing
> >> them may be
> >> > > >> >> > > excessive.
> >> > > >> >> > >
> >> > > >> >> > > > jthread_get_name... What will you do in that case?
> >> Let me
> >> > > >> guess you
> >> > > >> >> > > > will call j.l.Thread.getName. Right. Ok! In that
> >> case I see no
> >> > > >> >> > > > problems to call j.l.Thread.isDaemon. Do you
> >> agree? So it
> >> > > >> doesn't
> >> > > >> >> > >
> >> > > >> >> > > As I suggested earlier, the best way to handle
> >> daemonality would
> >> > > >> >> > > probably be in pure Java - in j.l.Thread (or
> >> > > >> j.l.VMThreadManager) or
> >> > > >> >> > > whatever. You already lifted it up to the jthread
> >> level, but
> >> > > >> what if
> >> > > >> >> > > we can go a little bit higher...
> >> > > >> >> > >
> >> > > >> >> > > > seems to be a good design to pass only part of the
> >> > > >> information to
> >> > > >> >> > > > jthread_atach. Lets look at the signature of
> >> > > >> >> AttachCurrentThread. It
> >> > > >> >> > > > takes exactly these three parameters (daemon,
> >> name, group)
> >> > > >> >> passed as a
> >> > > >> >> > > > structure. I was thinking about having exactly the
> >> same
> >> > > >> >> structure as
> >> > > >> >> > > > third parameter of jthread_attach but it occured
> >> to be more
> >> > > >> >> convinient
> >> > > >> >> > > > to pass them seperatly. Although I don't see
> >> strong reasons
> >> > > >> against
> >> > > >> >> > > > having a structure a third parameter.
> >> > > >> >> > >
> >> > > >> >> > > I see. Acually, I would love to keep the
> >> jthread_attach func-ty at
> >> > > >> >> the
> >> > > >> >> > > minimum level which will be needed to handle the
> >> only data that TM
> >> > > >> >> > > should be aware of. We need a formal boundary
> >> between jthread
> >> > > >> layer
> >> > > >> >> > > and vmcore (otherwise jthread won't have a much of
> >> sense, one may
> >> > > >> >> > > consider it just as a convenience set of functions
> >> in vmcore which
> >> > > >> >> are
> >> > > >> >> > > doing something with threading).
> >> > > >> >> > >
> >> > > >> >> > > >
> >> > > >> >> > > > > 2) Move the implementation of vm_create_jtrhead
> >> () to
> >> > > >> >> > > > > thread_java_basic.c - could it be written in
> >> pure JNI without
> >> > > >> >> using
> >> > > >> >> > > > > internal VM API like class_alloc_new_object()?
> >> > > >> >> > > >
> >> > > >> >> > > > Yes, this can be done but it doesn't fix the
> >> problem. You still
> >> > > >> >> need
> >> > > >> >> > > > to know about internal constructor of j.l.Thread
> >> > > >> >> > >
> >> > > >> >> > > That's bad. Given what you said, now it seems that
> >> the most
> >> > > >> >> preferable
> >> > > >> >> > > sequence for AttachCurrentThread impl still would be
> >> like:
> >> > > >> >> > > JNIEnv = vm_attach();
> >> > > >> >> > > jthread = create_jthread(JNIenv)
> >> > > >> >> > > jthread_attach(JNIEnv, jthread) // stores JNIEnv and
> >> Hythread into
> >> > > >> >> > > TLS, doesn't call vm_attach any longer.
> >> > > >> >> > > - this is almost what we had from the beginning...
> >> > > >> >> > >
> >> > > >> >> > > Thanks,
> >> > > >> >> > > Andrey.
> >> > > >> >> > >
> >> > > >> >> > > >
> >> > > >> >> > > >
> >> > > >> >> > > > Thanks
> >> > > >> >> > > > Evgueni
> >> > > >> >> > > > >
> >> > > >> >> > > > >
> >> > > >> >> > > > > Thanks,
> >> > > >> >> > > > > Andrey.
> >> > > >> >> > > > >
> >> > > >> >> > > > > >
> >> > > >> >> > > > > > Thank you
> >> > > >> >> > > > > > Evgueni
> >> > > >> >> > > > > >
> >> > > >> >> > > > > > On 10/2/06, Evgueni Brevnov
> >> <ev...@gmail.com>
> >> > > >> wrote:
> >> > > >> >> > > > > > > On 9/29/06, Andrey Chernyshev
> >> <a....@gmail.com>
> >> > > >> >> wrote:
> >> > > >> >> > > > > > > > On 9/29/06, Evgueni Brevnov
> >> <ev...@gmail.com>
> >> > > >> >> wrote:
> >> > > >> >> > > > > > > > > Artem,
> >> > > >> >> > > > > > > > >
> >> > > >> >> > > > > > > > > Thank you for your feedback.... find my
> >> inlined.....
> >> > > >> >> > > > > > > > >
> >> > > >> >> > > > > > > > > On 9/29/06, Artem Aliev
> >> <ar...@gmail.com> wrote:
> >> > > >> >> > > > > > > > > > Evgueni,
> >> > > >> >> > > > > > > > > >
> >> > > >> >> > > > > > > > > > I got most of your changes, but still
> >> disagree
> >> > > >> with all
> >> > > >> >> > > > > > > > > > hythread/jthread interface changes.
> >> Could leave
> >> > > >> >> interface unchanged.
> >> > > >> >> > > > > > > > > > See following possible solutions, that
> >> could solve
> >> > > >> >> the same problems
> >> > > >> >> > > > > > > > > > without interface changes.
> >> > > >> >> > > > > > > > > >
> >> > > >> >> > > > > > > > > >
> >> > > >> >> > > > > > > > > > 1) daemon attribute is a java
> >> specific. (Andrey
> >> > > >> >> mentioned this already).
> >> > > >> >> > > > > > > > > > Could you please move it back. to
> >> the jthread
> >> > > >> >> layer. It is better
> >> > > >> >> > > > > > > > > > to rename
> >> > > >> >> > > > > > > > > >
> >> hythread_wait_for_all_nondaemon_threads() to
> >> > > >> >> > > > > > > > > > jthread_wait_for_all_nondaemon_threads().
> >> > > >> >> > > > > > > > > Ok, I see no problems to move "daemon"
> >> to java layer.
> >> > > >> >> In that case:
> >> > > >> >> > > > > > > > > 1) I will move
> >> > > >> >> hythread_wait_for_all_nondaemon_threads() from
> >> > > >> >> > > > > > > > > thread_init.c to one which implements
> >> java layer.
> >> > > >> >> > > > > > > > > 2) I will move daemon field from
> >> HyThread structure.
> >> > > >> >> > > > > > > > >
> >> > > >> >> > > > > > > > > Agree?
> >> > > >> >> > > > > > > >
> >> > > >> >> > > > > > > > Sounds good to me.
> >> > > >> >> > > > > > >
> >> > > >> >> > > > > > > OK, will do that.
> >> > > >> >> > > > > > >
> >> > > >> >> > > > > > > >
> >> > > >> >> > > > > > > >
> >> > > >> >> > > > > > > > >
> >> > > >> >> > > > > > > > > >
> >> > > >> >> > > > > > > > > > 2) JavaVM could be retrieved from
> >> JNIEnv by
> >> > > >> >> jni_get_java_vm(). So
> >> > > >> >> > > > > > > > > > let the jthread_create() and others to
> >> use JNIEnv
> >> > > >> >> (that is passed from
> >> > > >> >> > > > > > > > > > java native method).
> >> > > >> >> > > > > > > > > > The vm_attach could get old JNI env
> >> and create new
> >> > > >> >> one for the new thread.
> >> > > >> >> > > > > > > > > > The first JNIEnv is created in
> >> CreateVM call and
> >> > > >> >> could be passed to
> >> > > >> >> > > > > > > > > > the first thread at startup.
> >> > > >> >> > > > > > > > > No, no, no. I completely disagree with
> >> that!!! Why do
> >> > > >> >> you like JNIEnv
> >> > > >> >> > > > > > > > > but JavaVM. Why do you think that
> >> passing JavaVM
> >> > > >> >> instead of JNIEnv
> >> > > >> >> > > > > > > > > makes TM less modular? I don't see any
> >> difference
> >> > > >> >> here.... It seems
> >> > > >> >> > > > > > > > > for me like a big big hack to grab
> >> JNIEnv from another
> >> > > >> >> thread and pass
> >> > > >> >> > > > > > > > > it to jthread_attach to perform
> >> operations in the
> >> > > >> >> current thread.
> >> > > >> >> > > > > > > >
> >> > > >> >> > > > > > > > TM needs to know JNIEnv, mainly for
> >> managing the
> >> > > >> >> references to
> >> > > >> >> > > > > > > > objects, throwing exceptions and calling
> >> run() method of
> >> > > >> >> a new thread.
> >> > > >> >> > > > > > > > JNI spec proposes that JNIEnv is valid
> >> within the given
> >> > > >> >> thread, this
> >> > > >> >> > > > > > > > is why TM holds the JNIEnv pointer at the
> >> moment. This
> >> > > >> >> is why TM likes
> >> > > >> >> > > > > > > > the JNIEnv.
> >> > > >> >> > > > > > > >
> >> > > >> >> > > > > > > > Having the JNIEnv, one is able to get
> >> JavaVM but not
> >> > > >> >> vise versa. This
> >> > > >> >> > > > > > > > is why TM doesn't like the JavaVM :)
> >> > > >> >> > > > > > > I see your point. Only one note this is true
> >> for already
> >> > > >> >> attached threads...
> >> > > >> >> > > > > > >
> >> > > >> >> > > > > > > >
> >> > > >> >> > > > > > > > I agree with you that there is a design
> >> flaw that the
> >> > > >> >> JNIEnv is copied
> >> > > >> >> > > > > > > > from the parent thread to a child thread
> >> during thread
> >> > > >> >> creation. I
> >> > > >> >> > > > > > > > think it could be resolved via vm_attach()
> >> hook - with
> >> > > >> >> this event, VM
> >> > > >> >> > > > > > > > might tell the TM what the JNIEnv pointer
> >> for new thread
> >> > > >> >> should be. I
> >> > > >> >> > > > > > > > think you did that by extending the
> >> vm_attach() call
> >> > > >> >> with the JNIEnv**
> >> > > >> >> > > > > > > > argument.
> >> > > >> >> > > > > > > >
> >> > > >> >> > > > > > > > What is not completely clear is, why do
> >> you have to pass
> >> > > >> >> the JavaVM
> >> > > >> >> > > > > > > > forth and back, once from VM to TM, and
> >> then back from
> >> > > >> >> TM to VM again?
> >> > > >> >> > > > > > > >
> >> > > >> >> > > > > > > > If you need to know in jthread_attach,
> >> which particular
> >> > > >> >> VM vm_attach()
> >> > > >> >> > > > > > > > event is coming from, you could have
> >> vm_attach like
> >> > > >> >> > > > > > > > vm_attach(JNIEnv* currentThreadEnv, JNIEnv**
> >> > > >> >> newThreadEnv).
> >> > > >> >> > > > > > > I'm a little bit confused.....Current thread
> >> hasn't been
> >> > > >> >> attached yet.
> >> > > >> >> > > > > > > So there is no JNIEnv for it yet. How it can
> >> be passed as
> >> > > >> >> the first
> >> > > >> >> > > > > > > parameter to vm_attach()?
> >> > > >> >> > > > > > >
> >> > > >> >> > > > > > > > Then you will be always able to get the
> >> JavaVM from the
> >> > > >> >> JNIEnv.
> >> > > >> >> > > > > > > > The only difference is that you are
> >> currently doing
> >> > > >> >> JNIEnv->JavaVM
> >> > > >> >> > > > > > > > conversion in the VMThreadManager, but why
> >> can't you
> >> > > >> >> just do this in
> >> > > >> >> > > > > > > > vm_attach() without changing the interface
> >> of the TM?
> >> > > >> >> > > > > > > > So far JavaVM really looks like an extra
> >> knowledge that
> >> > > >> >> TM doesn't
> >> > > >> >> > > > > > > > have to be aware of.
> >> > > >> >> > > > > > > >
> >> > > >> >> > > > > > > > > Moreover there is no JNIEnv when main
> >> thread attaches
> >> > > >> >> to VM. So we
> >> > > >> >> > > > > > > > > should either keep it as is or change
> >> original design
> >> > > >> >> of TM and attach
> >> > > >> >> > > > > > > > > thread to VM before attaching it to TM.
> >> In that case
> >> > > >> >> we will have
> >> > > >> >> > > > > > > > > valid JNIEnv which can be passed to
> >> jthread_atatch. We
> >> > > >> >> need to think
> >> > > >> >> > > > > > > > > over it twice before changing something....
> >> > > >> >> > > > > > > >
> >> > > >> >> > > > > > > > Right. For jthread_attach, JNIenv needs to
> >> be changed
> >> > > >> >> from being input
> >> > > >> >> > > > > > > > parameter to being the output parameter.
> >> The way how
> >> > > >> >> JNIenv is
> >> > > >> >> > > > > > > > obtained by TM should be vm_attach() event.
> >> > > >> >> > > > > > > OK, JNIEnv is output parameter. And it
> >> obtained by
> >> > > >> >> vm_attach(). This
> >> > > >> >> > > > > > > is exactly like I do in the patch. What I
> >> don't understand
> >> > > >> >> is how
> >> > > >> >> > > > > > > jthread_attach knows to which VM the thread
> >> should be
> >> > > >> >> attached? Do you
> >> > > >> >> > > > > > > suggest calling vm_attach first to create
> >> JNIEnv it pass
> >> > > >> >> it to
> >> > > >> >> > > > > > > jthread_attach?
> >> > > >> >> > > > > > >
> >> > > >> >> > > > > > > >
> >> > > >> >> > > > > > > > >
> >> > > >> >> > > > > > > > >
> >> > > >> >> > > > > > > > >
> >> > > >> >> > > > > > > > > >
> >> > > >> >> > > > > > > > > >
> >> > > >> >> > > > > > > > > > 4) Original classlib hythread do not use
> >> > > >> >> hythread_library_t in arguments,
> >> > > >> >> > > > > > > > > > It uses following code:
> >> > > >> >> > > > > > > > > >
> >> > > >> >> > > > > > > > > > hythread_library_t lib = GLOBAL_DATA
> >> > > >> >> (default_library);
> >> > > >> >> > > > > > > > > > or
> >> > > >> >> > > > > > > > > > hythread_library_t library = thread-
> >> >library;
> >> > > >> >> > > > > > > > > >
> >> > > >> >> > > > > > > > > > So could you please use the same
> >> mechanism and
> >> > > >> >> remove hythread_*_ex >functions.
> >> > > >> >> > > > > > > > > Let's see if classlib's hythread needs
> >> changing first.
> >> > > >> >> It seems for me
> >> > > >> >> > > > > > > > > such code prevents us from having multi VM.
> >> > > >> >> > > > > > > > >
> >> > > >> >> > > > > > > > > >
> >> > > >> >> > > > > > > > > > 5. You introduce more then one jni
> >> env, but still
> >> > > >> >> use global variable for it.
> >> > > >> >> > > > > > > > > > So all changes like following:
> >> > > >> >> > > > > > > > > > - JNIEnv *jenv = (JNIEnv*)
> >> jni_native_intf;
> >> > > >> >> > > > > > > > > > + JNIEnv *jenv = jni_native_intf;
> >> > > >> >> > > > > > > > > >
> >> > > >> >> > > > > > > > > > should be like:
> >> > > >> >> > > > > > > > > > - JNIEnv *jenv = (JNIEnv*)
> >> jni_native_intf;
> >> > > >> >> > > > > > > > > > + JNIEnv *jenv = get_jni_env
> >> (jthread_self());
> >> > > >> >> > > > > > > > >
> >> > > >> >> > > > > > > > > Ok, I see. I agree that global
> >> jni_native_intf should
> >> > > >> >> not be used.
> >> > > >> >> > > > > > > > > There was simple reason why I altered
> >> such lines.
> >> > > >> >> Because I changed
> >> > > >> >> > > > > > > > > the type of jni_native_intf and no
> >> casting operator
> >> > > >> >> is needed now. To
> >> > > >> >> > > > > > > > > be honest I think get_jni_env
> >> (jthread_self()) can be
> >> > > >> >> good as temporary
> >> > > >> >> > > > > > > > > solution only. Lets wait for design of
> >> multi VM and
> >> > > >> >> fix it according
> >> > > >> >> > > > > > > > > to it.
> >> > > >> >> > > > > > > >
> >> > > >> >> > > > > > > > While we are in JNI code, we always have
> >> the JNIenv (at
> >> > > >> >> least
> >> > > >> >> > > > > > > > initially it comes from Java code). If we
> >> consider VM
> >> > > >> >> code as if it
> >> > > >> >> > > > > > > > was a JNI application, then it seems like
> >> we should be
> >> > > >> >> just passing
> >> > > >> >> > > > > > > > JNIEnv as a parameter to all functions in
> >> VM. Or, we can
> >> > > >> >> be taking it
> >> > > >> >> > > > > > > > from TLS (via jthread_self()), depending
> >> on which way is
> >> > > >> >> faster...
> >> > > >> >> > > > > > > Agree.
> >> > > >> >> > > > > > >
> >> > > >> >> > > > > > > >
> >> > > >> >> > > > > > > > >
> >> > > >> >> > > > > > > > > >
> >> > > >> >> > > > > > > > > > 6). And small remarks:
> >> > > >> >> > > > > > > > > > +jint vm_init1(JavaVM_Internal * java_vm,
> >> > > >> >> JavaVMInitArgs * vm_arguments);
> >> > > >> >> > > > > > > > > > +jint vm_init2(JNIEnv_Internal *
> >> jni_env);
> >> > > >> >> > > > > > > > > > Could you make names more meaningful,
> >> then 1,2,3...?
> >> > > >> >> > > > > > > > > Ok, will do that.
> >> > > >> >> > > > > > > > >
> >> > > >> >> > > > > > > > > >
> >> > > >> >> > > > > > > > > > class VM_thread {
> >> > > >> >> > > > > > > > > > ...
> >> > > >> >> > > > > > > > > > + JNIEnv_Internal * jni_env;
> >> > > >> >> > > > > > > > > > The jthread already has the jni_env
> >> pointer, you do
> >> > > >> >> not need to
> >> > > >> >> > > > > > > > > > duplicate it here.
> >> > > >> >> > > > > > > > > > forexample by using
> >> > > >> >> jthread_get_JNI_env(jthread_self());
> >> > > >> >> > > > > > > > >
> >> > > >> >> > > > > > > > > Yes I know. I don't see any problems
> >> here. Some times
> >> > > >> >> it is much more
> >> > > >> >> > > > > > > > > convenient to get JNIEnv from VM_thread
> >> structure (and
> >> > > >> >> faster) instead
> >> > > >> >> > > > > > > > > of doing jthread_get_JNI_env(jthread_self
> >> ()). So I
> >> > > >> >> need strong
> >> > > >> >> > > > > > > > > arguments for removing it. Again it
> >> seems that should
> >> > > >> >> be addressed in
> >> > > >> >> > > > > > > > > design of multi VM. So lets forget about
> >> it for a
> >> > > >> >> while...
> >> > > >> >> > > > > > > >
> >> > > >> >> > > > > > > > I think that the data duplication would
> >> always serve as
> >> > > >> >> a potential
> >> > > >> >> > > > > > > > source of errors - while updating one copy
> >> of object,
> >> > > >> >> you may forget
> >> > > >> >> > > > > > > > to update the other, often resulting into
> >> a strange
> >> > > >> >> behavior of the
> >> > > >> >> > > > > > > > whole application. Let's see what are the
> >> specific
> >> > > >> >> performance
> >> > > >> >> > > > > > > > concerns that have to be addressed. To get
> >> VM_thread
> >> > > >> >> structure, you
> >> > > >> >> > > > > > > > would eventually go to the TLS, just like
> >> > > >> >> > > > > > > > jthread_get_JNI_env(jthread_self() would do.
> >> > > >> >> > > > > > > If there is already VM_thread structure for
> >> some reasons
> >> > > >> >> then there
> >> > > >> >> > > > > > > will be no extra access to TLS. It is
> >> definitely much
> >> > > >> more in
> >> > > >> >> > > > > > > jthread_get_JNI_env(jthread_self() than just
> >> one TLS
> >> > > >> >> access and one
> >> > > >> >> > > > > > > dereferncing. I don't think it is a really
> >> big problem
> >> > > >> >> now. Do you
> >> > > >> >> > > > > > > agree to look at this later. I guess multi VM
> >> > > >> >> implementation will
> >> > > >> >> > > > > > > alter it in any case.
> >> > > >> >> > > > > > >
> >> > > >> >> > > > > > > Thanks
> >> > > >> >> > > > > > > Evgueni
> >> > > >> >> > > > > > >
> >> > > >> >> > > > > > > >
> >> > > >> >> > > > > > > > Thanks,
> >> > > >> >> > > > > > > > Andrey.
> >> > > >> >> > > > > > > >
> >> > > >> >> > > > > > > > >
> >> > > >> >> > > > > > > > > Evgueni
> >> > > >> >> > > > > > > > > >
> >> > > >> >> > > > > > > > > > Thanks
> >> > > >> >> > > > > > > > > > Artem
> >> > > >> >> > > > > > > > > >
> >> > > >> >> > > > > > > > > > On 9/28/06, Evgueni Brevnov
> >> > > >> >> <ev...@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.
> >> > > >> >> > > > > > > > > > >
> >> > > >> >> > > > > > > > > > > Thanks
> >> > > >> >> > > > > > > > > > > Evgueni
> >> > > >> >> > > > > > > > > > >
> >> > > >> >> > > > > > > > > > > On 9/28/06, Geir Magnusson Jr.
> >> <ge...@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
> >> > > >> >> <we...@gmail.com> wrote:
> >> > > >> >> > > > > > > > > > > > >> On 9/26/06, Evgueni Brevnov
> >> > > >> >> <ev...@gmail.com> wrote:
> >> > > >> >> > > > > > > > > > > > >> >
> >> > > >> >> > > > > > > > > > > > >> > On 9/27/06, Andrey Chernyshev
> >> > > >> >> <a....@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
> >> > > >> >> > > > > > > > > > >
> >> > > >> >> > > > > > > > > > >
> >> > > >> >> > > > > > > > > >
> >> > > >> >> > > > > > > > > >
> >> > > >> >>
> >> ---------------------------------------------------------------------
> >> > > >> >> > > > > > > > > > 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
> >> > > >> >> > > > > > > > >
> >> > > >> >> > > > > > > > >
> >> > > >> >> > > > > > > >
> >> > > >> >> > > > > > > >
> >> > > >> >> > > > > > > > --
> >> > > >> >> > > > > > > > Andrey Chernyshev
> >> > > >> >> > > > > > > > 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
> >> > > >> >> > > > > >
> >> > > >> >> > > > > >
> >> > > >> >> > > > >
> >> > > >> >> > > > >
> >> > > >> >> > > > > --
> >> > > >> >> > > > > Andrey Chernyshev
> >> > > >> >> > > > > 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
> >> > > >> >> > > >
> >> > > >> >> > > >
> >> > > >> >> > >
> >> > > >> >> > >
> >> > > >> >> > > --
> >> > > >> >> > > Andrey Chernyshev
> >> > > >> >> > > 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
> >> > > >>
> >> > > >>
> >> > > >
> >> > > >
> >> ---------------------------------------------------------------------
> >> > > > 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
> >
>
>
> ---------------------------------------------------------------------
> 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
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Oct 9, 2006, at 10:38 AM, Evgueni Brevnov wrote:
> Geir,
>
> Did you pass tests on SUSE9?
No, I don't have a SUSE9 machine.
geir
>
> On 10/9/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>>
>> On Oct 9, 2006, at 9:58 AM, Salikh Zakirov wrote:
>>
>> > Geir Magnusson Jr. wrote:
>> >> I keep getting a failure when running the tests -
>> >>
>> >> test_jthread_get_all-threads failling the assertion at
>> >> test_ti_instrum.c:80
>> >>
>> >> geir
>> >
>> > I have just tried to test HARMONY-1582 patch on Linux/ia32 SUSE 9
>> > and Ubuntu 6.
>> > The smoke and unit tests both pass okay with and without
>> HARMONY-1582.
>>
>> How did you do it on Ubuntu 6? What compiler?
>> >
>> > However, Ubuntu 6 results are somewhat surprising:
>> > 1) DRLVM (Jitrino) does not compile on GCC 4.0.3
>> > 2) After applying a fix (HARMONY-1783), cunit tests fail on a clean
>> > SVN trunk.
>> >
>> > I thought it would be pointless to try to apply HARMONY-1582 before
>> > dealing
>> > with the failures.
>> >
>> > Just for your information, the failures I have seen are:
>> >
>> > ERROR: Assertion 'critical_tts' failed at /export/users/salikh/
>> > drlvm/trunk/vm/tests/unit/thread/test_java_monitors.c:546
>> > INFO: TEST test_jthread_monitor_enter: FAILED
>> > INFO: TEST test_jthread_monitor_try_enter start
>> > ERROR: Assertion 'critical_tts' failed at /export/users/salikh/
>> > drlvm/trunk/vm/tests/unit/thread/test_java_monitors.c:90
>> > INFO: TEST test_jthread_monitor_try_enter: FAILED
>> > ERROR: Assertion 'critical_tts' failed at /export/users/salikh/
>> > drlvm/trunk/vm/tests/unit/thread/test_ti_monitor_info.c:266
>> > INFO: TEST test_jthread_get_owned_monitors: FAILED
>> >
>> >
>> >
>> ---------------------------------------------------------------------
>> > 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
>
---------------------------------------------------------------------
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
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
Posted by Evgueni Brevnov <ev...@gmail.com>.
Geir,
Did you pass tests on SUSE9?
On 10/9/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>
> On Oct 9, 2006, at 9:58 AM, Salikh Zakirov wrote:
>
> > Geir Magnusson Jr. wrote:
> >> I keep getting a failure when running the tests -
> >>
> >> test_jthread_get_all-threads failling the assertion at
> >> test_ti_instrum.c:80
> >>
> >> geir
> >
> > I have just tried to test HARMONY-1582 patch on Linux/ia32 SUSE 9
> > and Ubuntu 6.
> > The smoke and unit tests both pass okay with and without HARMONY-1582.
>
> How did you do it on Ubuntu 6? What compiler?
> >
> > However, Ubuntu 6 results are somewhat surprising:
> > 1) DRLVM (Jitrino) does not compile on GCC 4.0.3
> > 2) After applying a fix (HARMONY-1783), cunit tests fail on a clean
> > SVN trunk.
> >
> > I thought it would be pointless to try to apply HARMONY-1582 before
> > dealing
> > with the failures.
> >
> > Just for your information, the failures I have seen are:
> >
> > ERROR: Assertion 'critical_tts' failed at /export/users/salikh/
> > drlvm/trunk/vm/tests/unit/thread/test_java_monitors.c:546
> > INFO: TEST test_jthread_monitor_enter: FAILED
> > INFO: TEST test_jthread_monitor_try_enter start
> > ERROR: Assertion 'critical_tts' failed at /export/users/salikh/
> > drlvm/trunk/vm/tests/unit/thread/test_java_monitors.c:90
> > INFO: TEST test_jthread_monitor_try_enter: FAILED
> > ERROR: Assertion 'critical_tts' failed at /export/users/salikh/
> > drlvm/trunk/vm/tests/unit/thread/test_ti_monitor_info.c:266
> > INFO: TEST test_jthread_get_owned_monitors: FAILED
> >
> >
> > ---------------------------------------------------------------------
> > 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
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
Posted by Salikh Zakirov <Sa...@Intel.com>.
Geir Magnusson Jr. wrote:
>
> On Oct 9, 2006, at 9:58 AM, Salikh Zakirov wrote:
>
>> Geir Magnusson Jr. wrote:
>>> I keep getting a failure when running the tests -
>>>
>>> test_jthread_get_all-threads failling the assertion at
>>> test_ti_instrum.c:80
>>>
>>> geir
>>
>> I have just tried to test HARMONY-1582 patch on Linux/ia32 SUSE 9 and
>> Ubuntu 6.
>> The smoke and unit tests both pass okay with and without HARMONY-1582.
>
> How did you do it on Ubuntu 6? What compiler?
Sorry for the confusion. I've missed the "SUSE9" word in the first message.
On top of that, I've used outdated workspace when testing on Ubuntu,
so errors I've got before have no sense at all.
I have rerunned tests on Ubuntu6 using clean workspace,
and the results are:
trunk trunk + HARMONY-1582
Linux/ia32/SUSE9: unit and smoke pass unit and smoke pass
Linux/ia32/Ubuntu6: unit and smoke pass intermittent failures***
*** On the first attempt, unit tests passed,
and smoke tests failed on gc.Finalizer
Running gc.Finalizer separately, however, passed.
On the second run, unit tests failed:
[echo] ERROR: Assertion '(thread_count)==(i + initial_thread_count)' failed at /export/users/salikh/drlvm/trunk/vm/tests/unit/thread/test_ti_instrum.c:80
[echo] INFO: TEST test_jthread_get_all_threads: FAILED
[echo] ERROR: Test failed: Wrong number waiting on monitor threads (/export/users/salikh/drlvm/trunk/vm/tests/unit/thread/test_ti_instrum.c:149)
[echo] INFO: TEST test_jthread_get_blocked_count: FAILED
[echo] INFO: TEST test_jthread_holds_lock: FAILED
[echo] ERROR: Assertion 'critical_tts' failed at /export/users/salikh/drlvm/trunk/vm/tests/unit/thread/test_ti_monitor_info.c:151
[echo] INFO: TEST test_jthread_get_lock_owner: FAILED
[echo] INFO: TEST test_jthread_get_owned_monitors start
[echo] ERROR: Assertion '(blocked_count)==(5 - i - 1)' failed at /export/users/salikh/drlvm/trunk/vm/tests/unit/thread/test_ti_monitor_info.c:212
[echo] INFO: TEST test_jthread_get_owned_monitors: FAILED
[echo] ERROR: Assertion 'critical_tts == NULL' failed at /export/users/salikh/drlvm/trunk/vm/tests/unit/thread/test_ti_monitor_info.c:276
---------------------------------------------------------------------
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
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Oct 9, 2006, at 9:58 AM, Salikh Zakirov wrote:
> Geir Magnusson Jr. wrote:
>> I keep getting a failure when running the tests -
>>
>> test_jthread_get_all-threads failling the assertion at
>> test_ti_instrum.c:80
>>
>> geir
>
> I have just tried to test HARMONY-1582 patch on Linux/ia32 SUSE 9
> and Ubuntu 6.
> The smoke and unit tests both pass okay with and without HARMONY-1582.
How did you do it on Ubuntu 6? What compiler?
>
> However, Ubuntu 6 results are somewhat surprising:
> 1) DRLVM (Jitrino) does not compile on GCC 4.0.3
> 2) After applying a fix (HARMONY-1783), cunit tests fail on a clean
> SVN trunk.
>
> I thought it would be pointless to try to apply HARMONY-1582 before
> dealing
> with the failures.
>
> Just for your information, the failures I have seen are:
>
> ERROR: Assertion 'critical_tts' failed at /export/users/salikh/
> drlvm/trunk/vm/tests/unit/thread/test_java_monitors.c:546
> INFO: TEST test_jthread_monitor_enter: FAILED
> INFO: TEST test_jthread_monitor_try_enter start
> ERROR: Assertion 'critical_tts' failed at /export/users/salikh/
> drlvm/trunk/vm/tests/unit/thread/test_java_monitors.c:90
> INFO: TEST test_jthread_monitor_try_enter: FAILED
> ERROR: Assertion 'critical_tts' failed at /export/users/salikh/
> drlvm/trunk/vm/tests/unit/thread/test_ti_monitor_info.c:266
> INFO: TEST test_jthread_get_owned_monitors: FAILED
>
>
> ---------------------------------------------------------------------
> 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
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Salikh Zakirov wrote:
> Geir Magnusson Jr. wrote:
>> I keep getting a failure when running the tests -
>>
>> test_jthread_get_all-threads failling the assertion at test_ti_instrum.c:80
>>
>> geir
>
> I have just tried to test HARMONY-1582 patch on Linux/ia32 SUSE 9 and Ubuntu 6.
> The smoke and unit tests both pass okay with and without HARMONY-1582.
>
> However, Ubuntu 6 results are somewhat surprising:
> 1) DRLVM (Jitrino) does not compile on GCC 4.0.3
> 2) After applying a fix (HARMONY-1783), cunit tests fail on a clean SVN trunk.
>
> I thought it would be pointless to try to apply HARMONY-1582 before dealing
> with the failures.
Yah, I'm not interested in getting lucky here. I couldn't get it to
work cleanly on ubuntu6 using gcc 3.4.6
>
> Just for your information, the failures I have seen are:
>
> ERROR: Assertion 'critical_tts' failed at /export/users/salikh/drlvm/trunk/vm/tests/unit/thread/test_java_monitors.c:546
> INFO: TEST test_jthread_monitor_enter: FAILED
> INFO: TEST test_jthread_monitor_try_enter start
> ERROR: Assertion 'critical_tts' failed at /export/users/salikh/drlvm/trunk/vm/tests/unit/thread/test_java_monitors.c:90
> INFO: TEST test_jthread_monitor_try_enter: FAILED
> ERROR: Assertion 'critical_tts' failed at /export/users/salikh/drlvm/trunk/vm/tests/unit/thread/test_ti_monitor_info.c:266
> INFO: TEST test_jthread_get_owned_monitors: FAILED
>
>
> ---------------------------------------------------------------------
> 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
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
Posted by Salikh Zakirov <Sa...@Intel.com>.
Geir Magnusson Jr. wrote:
> I keep getting a failure when running the tests -
>
> test_jthread_get_all-threads failling the assertion at test_ti_instrum.c:80
>
> geir
I have just tried to test HARMONY-1582 patch on Linux/ia32 SUSE 9 and Ubuntu 6.
The smoke and unit tests both pass okay with and without HARMONY-1582.
However, Ubuntu 6 results are somewhat surprising:
1) DRLVM (Jitrino) does not compile on GCC 4.0.3
2) After applying a fix (HARMONY-1783), cunit tests fail on a clean SVN trunk.
I thought it would be pointless to try to apply HARMONY-1582 before dealing
with the failures.
Just for your information, the failures I have seen are:
ERROR: Assertion 'critical_tts' failed at /export/users/salikh/drlvm/trunk/vm/tests/unit/thread/test_java_monitors.c:546
INFO: TEST test_jthread_monitor_enter: FAILED
INFO: TEST test_jthread_monitor_try_enter start
ERROR: Assertion 'critical_tts' failed at /export/users/salikh/drlvm/trunk/vm/tests/unit/thread/test_java_monitors.c:90
INFO: TEST test_jthread_monitor_try_enter: FAILED
ERROR: Assertion 'critical_tts' failed at /export/users/salikh/drlvm/trunk/vm/tests/unit/thread/test_ti_monitor_info.c:266
INFO: TEST test_jthread_get_owned_monitors: FAILED
---------------------------------------------------------------------
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
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
I keep getting a failure when running the tests -
test_jthread_get_all-threads failling the assertion at
test_ti_instrum.c:80
geir
On Oct 8, 2006, at 7:19 AM, Evgueni Brevnov wrote:
> While running cunit on Linux it turned out one test case fails some
> time. The fix is in tests.final.2.patch.
>
> So the last versions to be committed:
> invocation_api.final.patch
> build.final.2.patch
> tests.final.2.patch
>
> Evgueni
>
>
> On 10/8/06, Evgueni Brevnov <ev...@gmail.com> wrote:
>> I mahaged to resolve the problem on Linux.... will update
>> build.final.patch with build.final.2.patch in a while
>>
>> On 10/8/06, Evgueni Brevnov <ev...@gmail.com> wrote:
>> > Hi,
>> >
>> > Oh! Ooh! I did that..... I passed cunit, somke, kernel tests on
>> > Windows and smoke, kernel tests on Linux. Unfortunately I failed to
>> > link cunit tests on Linux so far. So I disabled cunit on Linux
>> until
>> > the problem is solved. I believe it is acceptable as short term
>> > solution. I found several problems in cunit tests. I will come
>> up with
>> > my findings later (not today).
>> >
>> > Use latest patches from HARMONY-1582. They are marked as final.
>> There
>> > are three patches. One for build module, one for cunit tests and
>> one
>> > for VM itself.
>> >
>> > Thanks
>> > Evgueni
>> >
>> >
>> > On 10/6/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>> > > Nooooooo! LOL
>> > >
>> > > I'm here waiting - This will unblock a whole bunch of things :)
>> > >
>> > > Thanks for the effort
>> > >
>> > > Evgueni Brevnov wrote:
>> > > > Geir,
>> > > >
>> > > > That's terrible. We have power outage....servers are down. I
>> can't
>> > > > send the patches now.... will do it tomorrow
>> > > >
>> > > > Evgueni
>> > > > On 10/5/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>> > > >> woo hoo! here we go...
>> > > >>
>> > > >>
>> > > >> Andrey Chernyshev wrote:
>> > > >> > Hi Evgueni,
>> > > >> >
>> > > >> > On 10/4/06, Evgueni Brevnov <ev...@gmail.com>
>> wrote:
>> > > >> >> Hi All,
>> > > >> >>
>> > > >> >> I have attached updated patch to the JIRA. It should
>> resolve remain
>> > > >> >> concerns. Andrey, could you give a green light now?
>> > > >> >
>> > > >> > Thanks for updating the patch! I agree it it can be
>> committed, at
>> > > >> > least signatures look good. 5 revisions seem like more
>> than enough :).
>> > > >> > Anyways, I think the remaining issues can be resolved
>> with additional
>> > > >> > patches. Thanks again for the good work and your patience.
>> > > >> >
>> > > >> > Thanks,
>> > > >> > Andrey.
>> > > >> >
>> > > >> >>
>> > > >> >> Thanks
>> > > >> >> Evgueni
>> > > >> >>
>> > > >> >> On 10/4/06, Evgueni Brevnov <ev...@gmail.com>
>> wrote:
>> > > >> >> > Andrey,
>> > > >> >> >
>> > > >> >> > I see your points. I think both approaches have
>> advantages and
>> > > >> >> > disadvantages. I think it is quite hard to say which
>> approach is
>> > > >> >> > better until we play with one VM only. I still feel
>> like introducing
>> > > >> >> > one more dependence is better than spreading code
>> which deals with
>> > > >> >> > attachment among VM and TM. We really get stuck. OK,
>> just because I
>> > > >> >> > want to move forward I will do required changes to remove
>> > > >> >> > vm_create_jthread from TM. I believe that will resolve
>> all our
>> > > >> >> > disagreements and the patch will be applied soon.
>> > > >> >> >
>> > > >> >> >
>> > > >> >> > Thanks
>> > > >> >> > Evgueni.
>> > > >> >> >
>> > > >> >> > On 10/4/06, Andrey Chernyshev
>> <a....@gmail.com> wrote:
>> > > >> >> > > On 10/3/06, Evgueni Brevnov
>> <ev...@gmail.com> wrote:
>> > > >> >> > > > On 10/3/06, Andrey Chernyshev
>> <a....@gmail.com> wrote:
>> > > >> >> > > > > On 10/2/06, Evgueni Brevnov
>> <ev...@gmail.com> wrote:
>> > > >> >> > > > > > Andrey,
>> > > >> >> > > > > >
>> > > >> >> > > > > > Just to be clear.... I agree with you it is more
>> > > >> convenient if
>> > > >> >> > > > > > jthread_create takes JNIEnv instead of JavaVM. It
>> > > >> reflects that
>> > > >> >> > > > > > current thread has been attached already. Do
>> you think it
>> > > >> >> makes sense
>> > > >> >> > > > > > to get rid of JNIEnv and use
>> jthread_get_JNI_env in that
>> > > >> case?
>> > > >> >> > > > >
>> > > >> >> > > > > The jthread_* layer is designed like if it were
>> a regular JNI
>> > > >> >> > > > > application which is meant to be called from the
>> Java code,
>> > > >> hence
>> > > >> >> > > > > every function on that layer receives JNIenv. We
>> can probably
>> > > >> >> get rid
>> > > >> >> > > > > of the JNEnv parameter for jthread_* functions,
>> assuming that
>> > > >> >> TM can
>> > > >> >> > > > > always extract JNIenv for the current thread with
>> > > >> >> > > > > jthread_get_JNI_env().
>> > > >> >> > > > > My only concern would be the performance - once
>> the JNIenv is
>> > > >> >> already
>> > > >> >> > > > > known for the native part of the kernel classes
>> impl, it
>> > > >> must be
>> > > >> >> > > > > cheaper to pass JNIEnv to TM as an extra
>> parameter rather than
>> > > >> >> extract
>> > > >> >> > > > > it from the TLS again.
>> > > >> >> > > > > Other than that, I see no strong advantages in
>> keeping JNIEnv
>> > > >> >> parameter.
>> > > >> >> > > > >
>> > > >> >> > > > >
>> > > >> >> > > > > > Regarding jthread_attach. I still didn't get
>> your point....
>> > > >> >> Clarify it
>> > > >> >> > > > > > please if you think jhread_attach should be
>> modified.
>> > > >> >> > > > >
>> > > >> >> > > > > Sorry for being not clear: I think for
>> jthread_attach, we have
>> > > >> >> two options:
>> > > >> >> > > > > 1) Make JNIEnv input parameter - it must be new
>> JNIEnv that VM
>> > > >> >> > > > > pre-allocates for the new Java thread.
>> jthread_attach
>> > > >> would just
>> > > >> >> > > > > associate it with the current thread.
>> > > >> >> > > > >
>> > > >> >> > > > > 2) Obtain JNIEnv via vm_attach() callback. In
>> this case, if
>> > > >> >> > > > > vm_attach() callback implementation needs to
>> know for which
>> > > >> >> JavaVM new
>> > > >> >> > > > > JNIenv has to be allocated, then we'll need to
>> add JavaVM as
>> > > >> >> input
>> > > >> >> > > > > parameter for jthread_attach().
>> > > >> >> > > > > I think both options should be fine, (1) would
>> probably
>> > > >> keep TM
>> > > >> >> > > > > interface a bit lighter, though (2) may look
>> more closer to
>> > > >> >> the JNI
>> > > >> >> > > > > invocation API idea.
>> > > >> >> > > > > So I think adding JavaVM specifically for
>> jthread_attach
>> > > >> may make
>> > > >> >> > > > > sense given the explanation you provided earlier.
>> > > >> >> > > > >
>> > > >> >> > > > > The concern I would have regarding the proposed
>> jthread_attach
>> > > >> >> > > > > implementation is a call to vm_create_jthread()
>> - this call
>> > > >> >> introduces
>> > > >> >> > > > > an extra dependency of TM on vmcore that I'd
>> prefer to be
>> > > >> >> avoided. In
>> > > >> >> > > > > the original version, jthread_attach() was
>> taking jthread
>> > > >> >> argument of
>> > > >> >> > > > > the already prepared j.l.Thread.
>> > > >> >> > > >
>> > > >> >> > > > I understand your concern. Unfortunately I don't
>> see what we
>> > > >> can do
>> > > >> >> > > > here. Let me explain. In the beginning you have an
>> unattached
>> > > >> >> native
>> > > >> >> > > > thread. To be able to call java code (which is
>> required for
>> > > >> >> > > > constructing j.l.Thread instance) the thread
>> should be attached
>> > > >> >> first.
>> > > >> >> > > > To be specific it should be attached to VM by
>> calling vm_attach
>> > > >> >> which
>> > > >> >> > > > will return a valid JNIEnv It is valid to use JNI
>> from that
>> > > >> moment.
>> > > >> >> > > > Obtained JNIEnv can be used to execute java code
>> and create
>> > > >> >> j.l.Thread
>> > > >> >> > > > instance. Since we do vm_attach in jthread_attach
>> we need to do
>> > > >> >> > > > vm_create_jthread inside jthread_atach as well.
>> > > >> >> > > > Of course it can be an alternative to do vm_attach
>> and
>> > > >> >> > > > vm_create_jthread outside of TM right before
>> jthread_attach.
>> > > >> >> Sure it
>> > > >> >> > > > will reduce one dependence between VM and TM. But
>> it seems like
>> > > >> >> > > > artificial action for me just because of
>> dependency....
>> > > >> >> > >
>> > > >> >> > > Why do you think it is artificial? I would rather
>> prefer not to
>> > > >> throw
>> > > >> >> > > vm_attach event from the jthread_attach() call at
>> all than to add
>> > > >> >> > > extra dependency. The idea of jthread layer is a
>> Java face to
>> > > >> >> > > hythread, it is meant to know either a little or
>> nothing about the
>> > > >> >> > > rest of VM. It may be logical to throw vm_attach
>> call from the
>> > > >> newly
>> > > >> >> > > created thread, because there is no other way to let
>> know VM
>> > > >> the new
>> > > >> >> > > thread is created. VM attach is a different case -
>> VM already
>> > > >> knows
>> > > >> >> > > about new Java thread at the time of the
>> AttachCurrentThread call.
>> > > >> >> > >
>> > > >> >> > > >
>> > > >> >> > > > > Do you think it makes sense to replace a single
>> jthread
>> > > >> >> parameter with
>> > > >> >> > > > > a variety of stuff (like thread group, name)? It
>> seems the
>> > > >> only
>> > > >> >> > > > > purpose of at these args is to be passed back to
>> VM for
>> > > >> >> > > > > vm_jthread_create(). I would suggest to change
>> this and try
>> > > >> doing
>> > > >> >> > > > > either of:
>> > > >> >> > > > > 1) Make signature of jthread_attach with 3 args,
>> JavaVM,
>> > > >> >> jthread and the daemon.
>> > > >> >> > > > Why do you want to pass daemon to TM but thread's
>> name and
>> > > >> >> group. Just
>> > > >> >> > > > because current TM doesn't need such information?
>> What if it is
>> > > >> >> > > > required to get thread name later? Say by introducing
>> > > >> >> > >
>> > > >> >> > > I imagine you need a daemon attribute since the TM
>> is still
>> > > >> managing
>> > > >> >> > > the thread daemonality. TM is not managing thread
>> name and group -
>> > > >> >> > > they are all kept on the Java level, hence passing
>> them may be
>> > > >> >> > > excessive.
>> > > >> >> > >
>> > > >> >> > > > jthread_get_name... What will you do in that case?
>> Let me
>> > > >> guess you
>> > > >> >> > > > will call j.l.Thread.getName. Right. Ok! In that
>> case I see no
>> > > >> >> > > > problems to call j.l.Thread.isDaemon. Do you
>> agree? So it
>> > > >> doesn't
>> > > >> >> > >
>> > > >> >> > > As I suggested earlier, the best way to handle
>> daemonality would
>> > > >> >> > > probably be in pure Java - in j.l.Thread (or
>> > > >> j.l.VMThreadManager) or
>> > > >> >> > > whatever. You already lifted it up to the jthread
>> level, but
>> > > >> what if
>> > > >> >> > > we can go a little bit higher...
>> > > >> >> > >
>> > > >> >> > > > seems to be a good design to pass only part of the
>> > > >> information to
>> > > >> >> > > > jthread_atach. Lets look at the signature of
>> > > >> >> AttachCurrentThread. It
>> > > >> >> > > > takes exactly these three parameters (daemon,
>> name, group)
>> > > >> >> passed as a
>> > > >> >> > > > structure. I was thinking about having exactly the
>> same
>> > > >> >> structure as
>> > > >> >> > > > third parameter of jthread_attach but it occured
>> to be more
>> > > >> >> convinient
>> > > >> >> > > > to pass them seperatly. Although I don't see
>> strong reasons
>> > > >> against
>> > > >> >> > > > having a structure a third parameter.
>> > > >> >> > >
>> > > >> >> > > I see. Acually, I would love to keep the
>> jthread_attach func-ty at
>> > > >> >> the
>> > > >> >> > > minimum level which will be needed to handle the
>> only data that TM
>> > > >> >> > > should be aware of. We need a formal boundary
>> between jthread
>> > > >> layer
>> > > >> >> > > and vmcore (otherwise jthread won't have a much of
>> sense, one may
>> > > >> >> > > consider it just as a convenience set of functions
>> in vmcore which
>> > > >> >> are
>> > > >> >> > > doing something with threading).
>> > > >> >> > >
>> > > >> >> > > >
>> > > >> >> > > > > 2) Move the implementation of vm_create_jtrhead
>> () to
>> > > >> >> > > > > thread_java_basic.c - could it be written in
>> pure JNI without
>> > > >> >> using
>> > > >> >> > > > > internal VM API like class_alloc_new_object()?
>> > > >> >> > > >
>> > > >> >> > > > Yes, this can be done but it doesn't fix the
>> problem. You still
>> > > >> >> need
>> > > >> >> > > > to know about internal constructor of j.l.Thread
>> > > >> >> > >
>> > > >> >> > > That's bad. Given what you said, now it seems that
>> the most
>> > > >> >> preferable
>> > > >> >> > > sequence for AttachCurrentThread impl still would be
>> like:
>> > > >> >> > > JNIEnv = vm_attach();
>> > > >> >> > > jthread = create_jthread(JNIenv)
>> > > >> >> > > jthread_attach(JNIEnv, jthread) // stores JNIEnv and
>> Hythread into
>> > > >> >> > > TLS, doesn't call vm_attach any longer.
>> > > >> >> > > - this is almost what we had from the beginning...
>> > > >> >> > >
>> > > >> >> > > Thanks,
>> > > >> >> > > Andrey.
>> > > >> >> > >
>> > > >> >> > > >
>> > > >> >> > > >
>> > > >> >> > > > Thanks
>> > > >> >> > > > Evgueni
>> > > >> >> > > > >
>> > > >> >> > > > >
>> > > >> >> > > > > Thanks,
>> > > >> >> > > > > Andrey.
>> > > >> >> > > > >
>> > > >> >> > > > > >
>> > > >> >> > > > > > Thank you
>> > > >> >> > > > > > Evgueni
>> > > >> >> > > > > >
>> > > >> >> > > > > > On 10/2/06, Evgueni Brevnov
>> <ev...@gmail.com>
>> > > >> wrote:
>> > > >> >> > > > > > > On 9/29/06, Andrey Chernyshev
>> <a....@gmail.com>
>> > > >> >> wrote:
>> > > >> >> > > > > > > > On 9/29/06, Evgueni Brevnov
>> <ev...@gmail.com>
>> > > >> >> wrote:
>> > > >> >> > > > > > > > > Artem,
>> > > >> >> > > > > > > > >
>> > > >> >> > > > > > > > > Thank you for your feedback.... find my
>> inlined.....
>> > > >> >> > > > > > > > >
>> > > >> >> > > > > > > > > On 9/29/06, Artem Aliev
>> <ar...@gmail.com> wrote:
>> > > >> >> > > > > > > > > > Evgueni,
>> > > >> >> > > > > > > > > >
>> > > >> >> > > > > > > > > > I got most of your changes, but still
>> disagree
>> > > >> with all
>> > > >> >> > > > > > > > > > hythread/jthread interface changes.
>> Could leave
>> > > >> >> interface unchanged.
>> > > >> >> > > > > > > > > > See following possible solutions, that
>> could solve
>> > > >> >> the same problems
>> > > >> >> > > > > > > > > > without interface changes.
>> > > >> >> > > > > > > > > >
>> > > >> >> > > > > > > > > >
>> > > >> >> > > > > > > > > > 1) daemon attribute is a java
>> specific. (Andrey
>> > > >> >> mentioned this already).
>> > > >> >> > > > > > > > > > Could you please move it back. to
>> the jthread
>> > > >> >> layer. It is better
>> > > >> >> > > > > > > > > > to rename
>> > > >> >> > > > > > > > > >
>> hythread_wait_for_all_nondaemon_threads() to
>> > > >> >> > > > > > > > > > jthread_wait_for_all_nondaemon_threads().
>> > > >> >> > > > > > > > > Ok, I see no problems to move "daemon"
>> to java layer.
>> > > >> >> In that case:
>> > > >> >> > > > > > > > > 1) I will move
>> > > >> >> hythread_wait_for_all_nondaemon_threads() from
>> > > >> >> > > > > > > > > thread_init.c to one which implements
>> java layer.
>> > > >> >> > > > > > > > > 2) I will move daemon field from
>> HyThread structure.
>> > > >> >> > > > > > > > >
>> > > >> >> > > > > > > > > Agree?
>> > > >> >> > > > > > > >
>> > > >> >> > > > > > > > Sounds good to me.
>> > > >> >> > > > > > >
>> > > >> >> > > > > > > OK, will do that.
>> > > >> >> > > > > > >
>> > > >> >> > > > > > > >
>> > > >> >> > > > > > > >
>> > > >> >> > > > > > > > >
>> > > >> >> > > > > > > > > >
>> > > >> >> > > > > > > > > > 2) JavaVM could be retrieved from
>> JNIEnv by
>> > > >> >> jni_get_java_vm(). So
>> > > >> >> > > > > > > > > > let the jthread_create() and others to
>> use JNIEnv
>> > > >> >> (that is passed from
>> > > >> >> > > > > > > > > > java native method).
>> > > >> >> > > > > > > > > > The vm_attach could get old JNI env
>> and create new
>> > > >> >> one for the new thread.
>> > > >> >> > > > > > > > > > The first JNIEnv is created in
>> CreateVM call and
>> > > >> >> could be passed to
>> > > >> >> > > > > > > > > > the first thread at startup.
>> > > >> >> > > > > > > > > No, no, no. I completely disagree with
>> that!!! Why do
>> > > >> >> you like JNIEnv
>> > > >> >> > > > > > > > > but JavaVM. Why do you think that
>> passing JavaVM
>> > > >> >> instead of JNIEnv
>> > > >> >> > > > > > > > > makes TM less modular? I don't see any
>> difference
>> > > >> >> here.... It seems
>> > > >> >> > > > > > > > > for me like a big big hack to grab
>> JNIEnv from another
>> > > >> >> thread and pass
>> > > >> >> > > > > > > > > it to jthread_attach to perform
>> operations in the
>> > > >> >> current thread.
>> > > >> >> > > > > > > >
>> > > >> >> > > > > > > > TM needs to know JNIEnv, mainly for
>> managing the
>> > > >> >> references to
>> > > >> >> > > > > > > > objects, throwing exceptions and calling
>> run() method of
>> > > >> >> a new thread.
>> > > >> >> > > > > > > > JNI spec proposes that JNIEnv is valid
>> within the given
>> > > >> >> thread, this
>> > > >> >> > > > > > > > is why TM holds the JNIEnv pointer at the
>> moment. This
>> > > >> >> is why TM likes
>> > > >> >> > > > > > > > the JNIEnv.
>> > > >> >> > > > > > > >
>> > > >> >> > > > > > > > Having the JNIEnv, one is able to get
>> JavaVM but not
>> > > >> >> vise versa. This
>> > > >> >> > > > > > > > is why TM doesn't like the JavaVM :)
>> > > >> >> > > > > > > I see your point. Only one note this is true
>> for already
>> > > >> >> attached threads...
>> > > >> >> > > > > > >
>> > > >> >> > > > > > > >
>> > > >> >> > > > > > > > I agree with you that there is a design
>> flaw that the
>> > > >> >> JNIEnv is copied
>> > > >> >> > > > > > > > from the parent thread to a child thread
>> during thread
>> > > >> >> creation. I
>> > > >> >> > > > > > > > think it could be resolved via vm_attach()
>> hook - with
>> > > >> >> this event, VM
>> > > >> >> > > > > > > > might tell the TM what the JNIEnv pointer
>> for new thread
>> > > >> >> should be. I
>> > > >> >> > > > > > > > think you did that by extending the
>> vm_attach() call
>> > > >> >> with the JNIEnv**
>> > > >> >> > > > > > > > argument.
>> > > >> >> > > > > > > >
>> > > >> >> > > > > > > > What is not completely clear is, why do
>> you have to pass
>> > > >> >> the JavaVM
>> > > >> >> > > > > > > > forth and back, once from VM to TM, and
>> then back from
>> > > >> >> TM to VM again?
>> > > >> >> > > > > > > >
>> > > >> >> > > > > > > > If you need to know in jthread_attach,
>> which particular
>> > > >> >> VM vm_attach()
>> > > >> >> > > > > > > > event is coming from, you could have
>> vm_attach like
>> > > >> >> > > > > > > > vm_attach(JNIEnv* currentThreadEnv, JNIEnv**
>> > > >> >> newThreadEnv).
>> > > >> >> > > > > > > I'm a little bit confused.....Current thread
>> hasn't been
>> > > >> >> attached yet.
>> > > >> >> > > > > > > So there is no JNIEnv for it yet. How it can
>> be passed as
>> > > >> >> the first
>> > > >> >> > > > > > > parameter to vm_attach()?
>> > > >> >> > > > > > >
>> > > >> >> > > > > > > > Then you will be always able to get the
>> JavaVM from the
>> > > >> >> JNIEnv.
>> > > >> >> > > > > > > > The only difference is that you are
>> currently doing
>> > > >> >> JNIEnv->JavaVM
>> > > >> >> > > > > > > > conversion in the VMThreadManager, but why
>> can't you
>> > > >> >> just do this in
>> > > >> >> > > > > > > > vm_attach() without changing the interface
>> of the TM?
>> > > >> >> > > > > > > > So far JavaVM really looks like an extra
>> knowledge that
>> > > >> >> TM doesn't
>> > > >> >> > > > > > > > have to be aware of.
>> > > >> >> > > > > > > >
>> > > >> >> > > > > > > > > Moreover there is no JNIEnv when main
>> thread attaches
>> > > >> >> to VM. So we
>> > > >> >> > > > > > > > > should either keep it as is or change
>> original design
>> > > >> >> of TM and attach
>> > > >> >> > > > > > > > > thread to VM before attaching it to TM.
>> In that case
>> > > >> >> we will have
>> > > >> >> > > > > > > > > valid JNIEnv which can be passed to
>> jthread_atatch. We
>> > > >> >> need to think
>> > > >> >> > > > > > > > > over it twice before changing something....
>> > > >> >> > > > > > > >
>> > > >> >> > > > > > > > Right. For jthread_attach, JNIenv needs to
>> be changed
>> > > >> >> from being input
>> > > >> >> > > > > > > > parameter to being the output parameter.
>> The way how
>> > > >> >> JNIenv is
>> > > >> >> > > > > > > > obtained by TM should be vm_attach() event.
>> > > >> >> > > > > > > OK, JNIEnv is output parameter. And it
>> obtained by
>> > > >> >> vm_attach(). This
>> > > >> >> > > > > > > is exactly like I do in the patch. What I
>> don't understand
>> > > >> >> is how
>> > > >> >> > > > > > > jthread_attach knows to which VM the thread
>> should be
>> > > >> >> attached? Do you
>> > > >> >> > > > > > > suggest calling vm_attach first to create
>> JNIEnv it pass
>> > > >> >> it to
>> > > >> >> > > > > > > jthread_attach?
>> > > >> >> > > > > > >
>> > > >> >> > > > > > > >
>> > > >> >> > > > > > > > >
>> > > >> >> > > > > > > > >
>> > > >> >> > > > > > > > >
>> > > >> >> > > > > > > > > >
>> > > >> >> > > > > > > > > >
>> > > >> >> > > > > > > > > > 4) Original classlib hythread do not use
>> > > >> >> hythread_library_t in arguments,
>> > > >> >> > > > > > > > > > It uses following code:
>> > > >> >> > > > > > > > > >
>> > > >> >> > > > > > > > > > hythread_library_t lib = GLOBAL_DATA
>> > > >> >> (default_library);
>> > > >> >> > > > > > > > > > or
>> > > >> >> > > > > > > > > > hythread_library_t library = thread-
>> >library;
>> > > >> >> > > > > > > > > >
>> > > >> >> > > > > > > > > > So could you please use the same
>> mechanism and
>> > > >> >> remove hythread_*_ex >functions.
>> > > >> >> > > > > > > > > Let's see if classlib's hythread needs
>> changing first.
>> > > >> >> It seems for me
>> > > >> >> > > > > > > > > such code prevents us from having multi VM.
>> > > >> >> > > > > > > > >
>> > > >> >> > > > > > > > > >
>> > > >> >> > > > > > > > > > 5. You introduce more then one jni
>> env, but still
>> > > >> >> use global variable for it.
>> > > >> >> > > > > > > > > > So all changes like following:
>> > > >> >> > > > > > > > > > - JNIEnv *jenv = (JNIEnv*)
>> jni_native_intf;
>> > > >> >> > > > > > > > > > + JNIEnv *jenv = jni_native_intf;
>> > > >> >> > > > > > > > > >
>> > > >> >> > > > > > > > > > should be like:
>> > > >> >> > > > > > > > > > - JNIEnv *jenv = (JNIEnv*)
>> jni_native_intf;
>> > > >> >> > > > > > > > > > + JNIEnv *jenv = get_jni_env
>> (jthread_self());
>> > > >> >> > > > > > > > >
>> > > >> >> > > > > > > > > Ok, I see. I agree that global
>> jni_native_intf should
>> > > >> >> not be used.
>> > > >> >> > > > > > > > > There was simple reason why I altered
>> such lines.
>> > > >> >> Because I changed
>> > > >> >> > > > > > > > > the type of jni_native_intf and no
>> casting operator
>> > > >> >> is needed now. To
>> > > >> >> > > > > > > > > be honest I think get_jni_env
>> (jthread_self()) can be
>> > > >> >> good as temporary
>> > > >> >> > > > > > > > > solution only. Lets wait for design of
>> multi VM and
>> > > >> >> fix it according
>> > > >> >> > > > > > > > > to it.
>> > > >> >> > > > > > > >
>> > > >> >> > > > > > > > While we are in JNI code, we always have
>> the JNIenv (at
>> > > >> >> least
>> > > >> >> > > > > > > > initially it comes from Java code). If we
>> consider VM
>> > > >> >> code as if it
>> > > >> >> > > > > > > > was a JNI application, then it seems like
>> we should be
>> > > >> >> just passing
>> > > >> >> > > > > > > > JNIEnv as a parameter to all functions in
>> VM. Or, we can
>> > > >> >> be taking it
>> > > >> >> > > > > > > > from TLS (via jthread_self()), depending
>> on which way is
>> > > >> >> faster...
>> > > >> >> > > > > > > Agree.
>> > > >> >> > > > > > >
>> > > >> >> > > > > > > >
>> > > >> >> > > > > > > > >
>> > > >> >> > > > > > > > > >
>> > > >> >> > > > > > > > > > 6). And small remarks:
>> > > >> >> > > > > > > > > > +jint vm_init1(JavaVM_Internal * java_vm,
>> > > >> >> JavaVMInitArgs * vm_arguments);
>> > > >> >> > > > > > > > > > +jint vm_init2(JNIEnv_Internal *
>> jni_env);
>> > > >> >> > > > > > > > > > Could you make names more meaningful,
>> then 1,2,3...?
>> > > >> >> > > > > > > > > Ok, will do that.
>> > > >> >> > > > > > > > >
>> > > >> >> > > > > > > > > >
>> > > >> >> > > > > > > > > > class VM_thread {
>> > > >> >> > > > > > > > > > ...
>> > > >> >> > > > > > > > > > + JNIEnv_Internal * jni_env;
>> > > >> >> > > > > > > > > > The jthread already has the jni_env
>> pointer, you do
>> > > >> >> not need to
>> > > >> >> > > > > > > > > > duplicate it here.
>> > > >> >> > > > > > > > > > forexample by using
>> > > >> >> jthread_get_JNI_env(jthread_self());
>> > > >> >> > > > > > > > >
>> > > >> >> > > > > > > > > Yes I know. I don't see any problems
>> here. Some times
>> > > >> >> it is much more
>> > > >> >> > > > > > > > > convenient to get JNIEnv from VM_thread
>> structure (and
>> > > >> >> faster) instead
>> > > >> >> > > > > > > > > of doing jthread_get_JNI_env(jthread_self
>> ()). So I
>> > > >> >> need strong
>> > > >> >> > > > > > > > > arguments for removing it. Again it
>> seems that should
>> > > >> >> be addressed in
>> > > >> >> > > > > > > > > design of multi VM. So lets forget about
>> it for a
>> > > >> >> while...
>> > > >> >> > > > > > > >
>> > > >> >> > > > > > > > I think that the data duplication would
>> always serve as
>> > > >> >> a potential
>> > > >> >> > > > > > > > source of errors - while updating one copy
>> of object,
>> > > >> >> you may forget
>> > > >> >> > > > > > > > to update the other, often resulting into
>> a strange
>> > > >> >> behavior of the
>> > > >> >> > > > > > > > whole application. Let's see what are the
>> specific
>> > > >> >> performance
>> > > >> >> > > > > > > > concerns that have to be addressed. To get
>> VM_thread
>> > > >> >> structure, you
>> > > >> >> > > > > > > > would eventually go to the TLS, just like
>> > > >> >> > > > > > > > jthread_get_JNI_env(jthread_self() would do.
>> > > >> >> > > > > > > If there is already VM_thread structure for
>> some reasons
>> > > >> >> then there
>> > > >> >> > > > > > > will be no extra access to TLS. It is
>> definitely much
>> > > >> more in
>> > > >> >> > > > > > > jthread_get_JNI_env(jthread_self() than just
>> one TLS
>> > > >> >> access and one
>> > > >> >> > > > > > > dereferncing. I don't think it is a really
>> big problem
>> > > >> >> now. Do you
>> > > >> >> > > > > > > agree to look at this later. I guess multi VM
>> > > >> >> implementation will
>> > > >> >> > > > > > > alter it in any case.
>> > > >> >> > > > > > >
>> > > >> >> > > > > > > Thanks
>> > > >> >> > > > > > > Evgueni
>> > > >> >> > > > > > >
>> > > >> >> > > > > > > >
>> > > >> >> > > > > > > > Thanks,
>> > > >> >> > > > > > > > Andrey.
>> > > >> >> > > > > > > >
>> > > >> >> > > > > > > > >
>> > > >> >> > > > > > > > > Evgueni
>> > > >> >> > > > > > > > > >
>> > > >> >> > > > > > > > > > Thanks
>> > > >> >> > > > > > > > > > Artem
>> > > >> >> > > > > > > > > >
>> > > >> >> > > > > > > > > > On 9/28/06, Evgueni Brevnov
>> > > >> >> <ev...@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.
>> > > >> >> > > > > > > > > > >
>> > > >> >> > > > > > > > > > > Thanks
>> > > >> >> > > > > > > > > > > Evgueni
>> > > >> >> > > > > > > > > > >
>> > > >> >> > > > > > > > > > > On 9/28/06, Geir Magnusson Jr.
>> <ge...@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
>> > > >> >> <we...@gmail.com> wrote:
>> > > >> >> > > > > > > > > > > > >> On 9/26/06, Evgueni Brevnov
>> > > >> >> <ev...@gmail.com> wrote:
>> > > >> >> > > > > > > > > > > > >> >
>> > > >> >> > > > > > > > > > > > >> > On 9/27/06, Andrey Chernyshev
>> > > >> >> <a....@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
>> > > >> >> > > > > > > > > > >
>> > > >> >> > > > > > > > > > >
>> > > >> >> > > > > > > > > >
>> > > >> >> > > > > > > > > >
>> > > >> >>
>> ---------------------------------------------------------------------
>> > > >> >> > > > > > > > > > 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
>> > > >> >> > > > > > > > >
>> > > >> >> > > > > > > > >
>> > > >> >> > > > > > > >
>> > > >> >> > > > > > > >
>> > > >> >> > > > > > > > --
>> > > >> >> > > > > > > > Andrey Chernyshev
>> > > >> >> > > > > > > > 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
>> > > >> >> > > > > >
>> > > >> >> > > > > >
>> > > >> >> > > > >
>> > > >> >> > > > >
>> > > >> >> > > > > --
>> > > >> >> > > > > Andrey Chernyshev
>> > > >> >> > > > > 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
>> > > >> >> > > >
>> > > >> >> > > >
>> > > >> >> > >
>> > > >> >> > >
>> > > >> >> > > --
>> > > >> >> > > Andrey Chernyshev
>> > > >> >> > > 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
>> > > >>
>> > > >>
>> > > >
>> > > >
>> ---------------------------------------------------------------------
>> > > > 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
>
---------------------------------------------------------------------
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
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
Posted by Evgueni Brevnov <ev...@gmail.com>.
While running cunit on Linux it turned out one test case fails some
time. The fix is in tests.final.2.patch.
So the last versions to be committed:
invocation_api.final.patch
build.final.2.patch
tests.final.2.patch
Evgueni
On 10/8/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> I mahaged to resolve the problem on Linux.... will update
> build.final.patch with build.final.2.patch in a while
>
> On 10/8/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> > Hi,
> >
> > Oh! Ooh! I did that..... I passed cunit, somke, kernel tests on
> > Windows and smoke, kernel tests on Linux. Unfortunately I failed to
> > link cunit tests on Linux so far. So I disabled cunit on Linux until
> > the problem is solved. I believe it is acceptable as short term
> > solution. I found several problems in cunit tests. I will come up with
> > my findings later (not today).
> >
> > Use latest patches from HARMONY-1582. They are marked as final. There
> > are three patches. One for build module, one for cunit tests and one
> > for VM itself.
> >
> > Thanks
> > Evgueni
> >
> >
> > On 10/6/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> > > Nooooooo! LOL
> > >
> > > I'm here waiting - This will unblock a whole bunch of things :)
> > >
> > > Thanks for the effort
> > >
> > > Evgueni Brevnov wrote:
> > > > Geir,
> > > >
> > > > That's terrible. We have power outage....servers are down. I can't
> > > > send the patches now.... will do it tomorrow
> > > >
> > > > Evgueni
> > > > On 10/5/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> > > >> woo hoo! here we go...
> > > >>
> > > >>
> > > >> Andrey Chernyshev wrote:
> > > >> > Hi Evgueni,
> > > >> >
> > > >> > On 10/4/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> > > >> >> Hi All,
> > > >> >>
> > > >> >> I have attached updated patch to the JIRA. It should resolve remain
> > > >> >> concerns. Andrey, could you give a green light now?
> > > >> >
> > > >> > Thanks for updating the patch! I agree it it can be committed, at
> > > >> > least signatures look good. 5 revisions seem like more than enough :).
> > > >> > Anyways, I think the remaining issues can be resolved with additional
> > > >> > patches. Thanks again for the good work and your patience.
> > > >> >
> > > >> > Thanks,
> > > >> > Andrey.
> > > >> >
> > > >> >>
> > > >> >> Thanks
> > > >> >> Evgueni
> > > >> >>
> > > >> >> On 10/4/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> > > >> >> > Andrey,
> > > >> >> >
> > > >> >> > I see your points. I think both approaches have advantages and
> > > >> >> > disadvantages. I think it is quite hard to say which approach is
> > > >> >> > better until we play with one VM only. I still feel like introducing
> > > >> >> > one more dependence is better than spreading code which deals with
> > > >> >> > attachment among VM and TM. We really get stuck. OK, just because I
> > > >> >> > want to move forward I will do required changes to remove
> > > >> >> > vm_create_jthread from TM. I believe that will resolve all our
> > > >> >> > disagreements and the patch will be applied soon.
> > > >> >> >
> > > >> >> >
> > > >> >> > Thanks
> > > >> >> > Evgueni.
> > > >> >> >
> > > >> >> > On 10/4/06, Andrey Chernyshev <a....@gmail.com> wrote:
> > > >> >> > > On 10/3/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> > > >> >> > > > On 10/3/06, Andrey Chernyshev <a....@gmail.com> wrote:
> > > >> >> > > > > On 10/2/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> > > >> >> > > > > > Andrey,
> > > >> >> > > > > >
> > > >> >> > > > > > Just to be clear.... I agree with you it is more
> > > >> convenient if
> > > >> >> > > > > > jthread_create takes JNIEnv instead of JavaVM. It
> > > >> reflects that
> > > >> >> > > > > > current thread has been attached already. Do you think it
> > > >> >> makes sense
> > > >> >> > > > > > to get rid of JNIEnv and use jthread_get_JNI_env in that
> > > >> case?
> > > >> >> > > > >
> > > >> >> > > > > The jthread_* layer is designed like if it were a regular JNI
> > > >> >> > > > > application which is meant to be called from the Java code,
> > > >> hence
> > > >> >> > > > > every function on that layer receives JNIenv. We can probably
> > > >> >> get rid
> > > >> >> > > > > of the JNEnv parameter for jthread_* functions, assuming that
> > > >> >> TM can
> > > >> >> > > > > always extract JNIenv for the current thread with
> > > >> >> > > > > jthread_get_JNI_env().
> > > >> >> > > > > My only concern would be the performance - once the JNIenv is
> > > >> >> already
> > > >> >> > > > > known for the native part of the kernel classes impl, it
> > > >> must be
> > > >> >> > > > > cheaper to pass JNIEnv to TM as an extra parameter rather than
> > > >> >> extract
> > > >> >> > > > > it from the TLS again.
> > > >> >> > > > > Other than that, I see no strong advantages in keeping JNIEnv
> > > >> >> parameter.
> > > >> >> > > > >
> > > >> >> > > > >
> > > >> >> > > > > > Regarding jthread_attach. I still didn't get your point....
> > > >> >> Clarify it
> > > >> >> > > > > > please if you think jhread_attach should be modified.
> > > >> >> > > > >
> > > >> >> > > > > Sorry for being not clear: I think for jthread_attach, we have
> > > >> >> two options:
> > > >> >> > > > > 1) Make JNIEnv input parameter - it must be new JNIEnv that VM
> > > >> >> > > > > pre-allocates for the new Java thread. jthread_attach
> > > >> would just
> > > >> >> > > > > associate it with the current thread.
> > > >> >> > > > >
> > > >> >> > > > > 2) Obtain JNIEnv via vm_attach() callback. In this case, if
> > > >> >> > > > > vm_attach() callback implementation needs to know for which
> > > >> >> JavaVM new
> > > >> >> > > > > JNIenv has to be allocated, then we'll need to add JavaVM as
> > > >> >> input
> > > >> >> > > > > parameter for jthread_attach().
> > > >> >> > > > > I think both options should be fine, (1) would probably
> > > >> keep TM
> > > >> >> > > > > interface a bit lighter, though (2) may look more closer to
> > > >> >> the JNI
> > > >> >> > > > > invocation API idea.
> > > >> >> > > > > So I think adding JavaVM specifically for jthread_attach
> > > >> may make
> > > >> >> > > > > sense given the explanation you provided earlier.
> > > >> >> > > > >
> > > >> >> > > > > The concern I would have regarding the proposed jthread_attach
> > > >> >> > > > > implementation is a call to vm_create_jthread() - this call
> > > >> >> introduces
> > > >> >> > > > > an extra dependency of TM on vmcore that I'd prefer to be
> > > >> >> avoided. In
> > > >> >> > > > > the original version, jthread_attach() was taking jthread
> > > >> >> argument of
> > > >> >> > > > > the already prepared j.l.Thread.
> > > >> >> > > >
> > > >> >> > > > I understand your concern. Unfortunately I don't see what we
> > > >> can do
> > > >> >> > > > here. Let me explain. In the beginning you have an unattached
> > > >> >> native
> > > >> >> > > > thread. To be able to call java code (which is required for
> > > >> >> > > > constructing j.l.Thread instance) the thread should be attached
> > > >> >> first.
> > > >> >> > > > To be specific it should be attached to VM by calling vm_attach
> > > >> >> which
> > > >> >> > > > will return a valid JNIEnv It is valid to use JNI from that
> > > >> moment.
> > > >> >> > > > Obtained JNIEnv can be used to execute java code and create
> > > >> >> j.l.Thread
> > > >> >> > > > instance. Since we do vm_attach in jthread_attach we need to do
> > > >> >> > > > vm_create_jthread inside jthread_atach as well.
> > > >> >> > > > Of course it can be an alternative to do vm_attach and
> > > >> >> > > > vm_create_jthread outside of TM right before jthread_attach.
> > > >> >> Sure it
> > > >> >> > > > will reduce one dependence between VM and TM. But it seems like
> > > >> >> > > > artificial action for me just because of dependency....
> > > >> >> > >
> > > >> >> > > Why do you think it is artificial? I would rather prefer not to
> > > >> throw
> > > >> >> > > vm_attach event from the jthread_attach() call at all than to add
> > > >> >> > > extra dependency. The idea of jthread layer is a Java face to
> > > >> >> > > hythread, it is meant to know either a little or nothing about the
> > > >> >> > > rest of VM. It may be logical to throw vm_attach call from the
> > > >> newly
> > > >> >> > > created thread, because there is no other way to let know VM
> > > >> the new
> > > >> >> > > thread is created. VM attach is a different case - VM already
> > > >> knows
> > > >> >> > > about new Java thread at the time of the AttachCurrentThread call.
> > > >> >> > >
> > > >> >> > > >
> > > >> >> > > > > Do you think it makes sense to replace a single jthread
> > > >> >> parameter with
> > > >> >> > > > > a variety of stuff (like thread group, name)? It seems the
> > > >> only
> > > >> >> > > > > purpose of at these args is to be passed back to VM for
> > > >> >> > > > > vm_jthread_create(). I would suggest to change this and try
> > > >> doing
> > > >> >> > > > > either of:
> > > >> >> > > > > 1) Make signature of jthread_attach with 3 args, JavaVM,
> > > >> >> jthread and the daemon.
> > > >> >> > > > Why do you want to pass daemon to TM but thread's name and
> > > >> >> group. Just
> > > >> >> > > > because current TM doesn't need such information? What if it is
> > > >> >> > > > required to get thread name later? Say by introducing
> > > >> >> > >
> > > >> >> > > I imagine you need a daemon attribute since the TM is still
> > > >> managing
> > > >> >> > > the thread daemonality. TM is not managing thread name and group -
> > > >> >> > > they are all kept on the Java level, hence passing them may be
> > > >> >> > > excessive.
> > > >> >> > >
> > > >> >> > > > jthread_get_name... What will you do in that case? Let me
> > > >> guess you
> > > >> >> > > > will call j.l.Thread.getName. Right. Ok! In that case I see no
> > > >> >> > > > problems to call j.l.Thread.isDaemon. Do you agree? So it
> > > >> doesn't
> > > >> >> > >
> > > >> >> > > As I suggested earlier, the best way to handle daemonality would
> > > >> >> > > probably be in pure Java - in j.l.Thread (or
> > > >> j.l.VMThreadManager) or
> > > >> >> > > whatever. You already lifted it up to the jthread level, but
> > > >> what if
> > > >> >> > > we can go a little bit higher...
> > > >> >> > >
> > > >> >> > > > seems to be a good design to pass only part of the
> > > >> information to
> > > >> >> > > > jthread_atach. Lets look at the signature of
> > > >> >> AttachCurrentThread. It
> > > >> >> > > > takes exactly these three parameters (daemon, name, group)
> > > >> >> passed as a
> > > >> >> > > > structure. I was thinking about having exactly the same
> > > >> >> structure as
> > > >> >> > > > third parameter of jthread_attach but it occured to be more
> > > >> >> convinient
> > > >> >> > > > to pass them seperatly. Although I don't see strong reasons
> > > >> against
> > > >> >> > > > having a structure a third parameter.
> > > >> >> > >
> > > >> >> > > I see. Acually, I would love to keep the jthread_attach func-ty at
> > > >> >> the
> > > >> >> > > minimum level which will be needed to handle the only data that TM
> > > >> >> > > should be aware of. We need a formal boundary between jthread
> > > >> layer
> > > >> >> > > and vmcore (otherwise jthread won't have a much of sense, one may
> > > >> >> > > consider it just as a convenience set of functions in vmcore which
> > > >> >> are
> > > >> >> > > doing something with threading).
> > > >> >> > >
> > > >> >> > > >
> > > >> >> > > > > 2) Move the implementation of vm_create_jtrhead() to
> > > >> >> > > > > thread_java_basic.c - could it be written in pure JNI without
> > > >> >> using
> > > >> >> > > > > internal VM API like class_alloc_new_object()?
> > > >> >> > > >
> > > >> >> > > > Yes, this can be done but it doesn't fix the problem. You still
> > > >> >> need
> > > >> >> > > > to know about internal constructor of j.l.Thread
> > > >> >> > >
> > > >> >> > > That's bad. Given what you said, now it seems that the most
> > > >> >> preferable
> > > >> >> > > sequence for AttachCurrentThread impl still would be like:
> > > >> >> > > JNIEnv = vm_attach();
> > > >> >> > > jthread = create_jthread(JNIenv)
> > > >> >> > > jthread_attach(JNIEnv, jthread) // stores JNIEnv and Hythread into
> > > >> >> > > TLS, doesn't call vm_attach any longer.
> > > >> >> > > - this is almost what we had from the beginning...
> > > >> >> > >
> > > >> >> > > Thanks,
> > > >> >> > > Andrey.
> > > >> >> > >
> > > >> >> > > >
> > > >> >> > > >
> > > >> >> > > > Thanks
> > > >> >> > > > Evgueni
> > > >> >> > > > >
> > > >> >> > > > >
> > > >> >> > > > > Thanks,
> > > >> >> > > > > Andrey.
> > > >> >> > > > >
> > > >> >> > > > > >
> > > >> >> > > > > > Thank you
> > > >> >> > > > > > Evgueni
> > > >> >> > > > > >
> > > >> >> > > > > > On 10/2/06, Evgueni Brevnov <ev...@gmail.com>
> > > >> wrote:
> > > >> >> > > > > > > On 9/29/06, Andrey Chernyshev <a....@gmail.com>
> > > >> >> wrote:
> > > >> >> > > > > > > > On 9/29/06, Evgueni Brevnov <ev...@gmail.com>
> > > >> >> wrote:
> > > >> >> > > > > > > > > Artem,
> > > >> >> > > > > > > > >
> > > >> >> > > > > > > > > Thank you for your feedback.... find my inlined.....
> > > >> >> > > > > > > > >
> > > >> >> > > > > > > > > On 9/29/06, Artem Aliev <ar...@gmail.com> wrote:
> > > >> >> > > > > > > > > > Evgueni,
> > > >> >> > > > > > > > > >
> > > >> >> > > > > > > > > > I got most of your changes, but still disagree
> > > >> with all
> > > >> >> > > > > > > > > > hythread/jthread interface changes. Could leave
> > > >> >> interface unchanged.
> > > >> >> > > > > > > > > > See following possible solutions, that could solve
> > > >> >> the same problems
> > > >> >> > > > > > > > > > without interface changes.
> > > >> >> > > > > > > > > >
> > > >> >> > > > > > > > > >
> > > >> >> > > > > > > > > > 1) daemon attribute is a java specific. (Andrey
> > > >> >> mentioned this already).
> > > >> >> > > > > > > > > > Could you please move it back. to the jthread
> > > >> >> layer. It is better
> > > >> >> > > > > > > > > > to rename
> > > >> >> > > > > > > > > > hythread_wait_for_all_nondaemon_threads() to
> > > >> >> > > > > > > > > > jthread_wait_for_all_nondaemon_threads().
> > > >> >> > > > > > > > > Ok, I see no problems to move "daemon" to java layer.
> > > >> >> In that case:
> > > >> >> > > > > > > > > 1) I will move
> > > >> >> hythread_wait_for_all_nondaemon_threads() from
> > > >> >> > > > > > > > > thread_init.c to one which implements java layer.
> > > >> >> > > > > > > > > 2) I will move daemon field from HyThread structure.
> > > >> >> > > > > > > > >
> > > >> >> > > > > > > > > Agree?
> > > >> >> > > > > > > >
> > > >> >> > > > > > > > Sounds good to me.
> > > >> >> > > > > > >
> > > >> >> > > > > > > OK, will do that.
> > > >> >> > > > > > >
> > > >> >> > > > > > > >
> > > >> >> > > > > > > >
> > > >> >> > > > > > > > >
> > > >> >> > > > > > > > > >
> > > >> >> > > > > > > > > > 2) JavaVM could be retrieved from JNIEnv by
> > > >> >> jni_get_java_vm(). So
> > > >> >> > > > > > > > > > let the jthread_create() and others to use JNIEnv
> > > >> >> (that is passed from
> > > >> >> > > > > > > > > > java native method).
> > > >> >> > > > > > > > > > The vm_attach could get old JNI env and create new
> > > >> >> one for the new thread.
> > > >> >> > > > > > > > > > The first JNIEnv is created in CreateVM call and
> > > >> >> could be passed to
> > > >> >> > > > > > > > > > the first thread at startup.
> > > >> >> > > > > > > > > No, no, no. I completely disagree with that!!! Why do
> > > >> >> you like JNIEnv
> > > >> >> > > > > > > > > but JavaVM. Why do you think that passing JavaVM
> > > >> >> instead of JNIEnv
> > > >> >> > > > > > > > > makes TM less modular? I don't see any difference
> > > >> >> here.... It seems
> > > >> >> > > > > > > > > for me like a big big hack to grab JNIEnv from another
> > > >> >> thread and pass
> > > >> >> > > > > > > > > it to jthread_attach to perform operations in the
> > > >> >> current thread.
> > > >> >> > > > > > > >
> > > >> >> > > > > > > > TM needs to know JNIEnv, mainly for managing the
> > > >> >> references to
> > > >> >> > > > > > > > objects, throwing exceptions and calling run() method of
> > > >> >> a new thread.
> > > >> >> > > > > > > > JNI spec proposes that JNIEnv is valid within the given
> > > >> >> thread, this
> > > >> >> > > > > > > > is why TM holds the JNIEnv pointer at the moment. This
> > > >> >> is why TM likes
> > > >> >> > > > > > > > the JNIEnv.
> > > >> >> > > > > > > >
> > > >> >> > > > > > > > Having the JNIEnv, one is able to get JavaVM but not
> > > >> >> vise versa. This
> > > >> >> > > > > > > > is why TM doesn't like the JavaVM :)
> > > >> >> > > > > > > I see your point. Only one note this is true for already
> > > >> >> attached threads...
> > > >> >> > > > > > >
> > > >> >> > > > > > > >
> > > >> >> > > > > > > > I agree with you that there is a design flaw that the
> > > >> >> JNIEnv is copied
> > > >> >> > > > > > > > from the parent thread to a child thread during thread
> > > >> >> creation. I
> > > >> >> > > > > > > > think it could be resolved via vm_attach() hook - with
> > > >> >> this event, VM
> > > >> >> > > > > > > > might tell the TM what the JNIEnv pointer for new thread
> > > >> >> should be. I
> > > >> >> > > > > > > > think you did that by extending the vm_attach() call
> > > >> >> with the JNIEnv**
> > > >> >> > > > > > > > argument.
> > > >> >> > > > > > > >
> > > >> >> > > > > > > > What is not completely clear is, why do you have to pass
> > > >> >> the JavaVM
> > > >> >> > > > > > > > forth and back, once from VM to TM, and then back from
> > > >> >> TM to VM again?
> > > >> >> > > > > > > >
> > > >> >> > > > > > > > If you need to know in jthread_attach, which particular
> > > >> >> VM vm_attach()
> > > >> >> > > > > > > > event is coming from, you could have vm_attach like
> > > >> >> > > > > > > > vm_attach(JNIEnv* currentThreadEnv, JNIEnv**
> > > >> >> newThreadEnv).
> > > >> >> > > > > > > I'm a little bit confused.....Current thread hasn't been
> > > >> >> attached yet.
> > > >> >> > > > > > > So there is no JNIEnv for it yet. How it can be passed as
> > > >> >> the first
> > > >> >> > > > > > > parameter to vm_attach()?
> > > >> >> > > > > > >
> > > >> >> > > > > > > > Then you will be always able to get the JavaVM from the
> > > >> >> JNIEnv.
> > > >> >> > > > > > > > The only difference is that you are currently doing
> > > >> >> JNIEnv->JavaVM
> > > >> >> > > > > > > > conversion in the VMThreadManager, but why can't you
> > > >> >> just do this in
> > > >> >> > > > > > > > vm_attach() without changing the interface of the TM?
> > > >> >> > > > > > > > So far JavaVM really looks like an extra knowledge that
> > > >> >> TM doesn't
> > > >> >> > > > > > > > have to be aware of.
> > > >> >> > > > > > > >
> > > >> >> > > > > > > > > Moreover there is no JNIEnv when main thread attaches
> > > >> >> to VM. So we
> > > >> >> > > > > > > > > should either keep it as is or change original design
> > > >> >> of TM and attach
> > > >> >> > > > > > > > > thread to VM before attaching it to TM. In that case
> > > >> >> we will have
> > > >> >> > > > > > > > > valid JNIEnv which can be passed to jthread_atatch. We
> > > >> >> need to think
> > > >> >> > > > > > > > > over it twice before changing something....
> > > >> >> > > > > > > >
> > > >> >> > > > > > > > Right. For jthread_attach, JNIenv needs to be changed
> > > >> >> from being input
> > > >> >> > > > > > > > parameter to being the output parameter. The way how
> > > >> >> JNIenv is
> > > >> >> > > > > > > > obtained by TM should be vm_attach() event.
> > > >> >> > > > > > > OK, JNIEnv is output parameter. And it obtained by
> > > >> >> vm_attach(). This
> > > >> >> > > > > > > is exactly like I do in the patch. What I don't understand
> > > >> >> is how
> > > >> >> > > > > > > jthread_attach knows to which VM the thread should be
> > > >> >> attached? Do you
> > > >> >> > > > > > > suggest calling vm_attach first to create JNIEnv it pass
> > > >> >> it to
> > > >> >> > > > > > > jthread_attach?
> > > >> >> > > > > > >
> > > >> >> > > > > > > >
> > > >> >> > > > > > > > >
> > > >> >> > > > > > > > >
> > > >> >> > > > > > > > >
> > > >> >> > > > > > > > > >
> > > >> >> > > > > > > > > >
> > > >> >> > > > > > > > > > 4) Original classlib hythread do not use
> > > >> >> hythread_library_t in arguments,
> > > >> >> > > > > > > > > > It uses following code:
> > > >> >> > > > > > > > > >
> > > >> >> > > > > > > > > > hythread_library_t lib = GLOBAL_DATA
> > > >> >> (default_library);
> > > >> >> > > > > > > > > > or
> > > >> >> > > > > > > > > > hythread_library_t library = thread->library;
> > > >> >> > > > > > > > > >
> > > >> >> > > > > > > > > > So could you please use the same mechanism and
> > > >> >> remove hythread_*_ex >functions.
> > > >> >> > > > > > > > > Let's see if classlib's hythread needs changing first.
> > > >> >> It seems for me
> > > >> >> > > > > > > > > such code prevents us from having multi VM.
> > > >> >> > > > > > > > >
> > > >> >> > > > > > > > > >
> > > >> >> > > > > > > > > > 5. You introduce more then one jni env, but still
> > > >> >> use global variable for it.
> > > >> >> > > > > > > > > > So all changes like following:
> > > >> >> > > > > > > > > > - JNIEnv *jenv = (JNIEnv*)jni_native_intf;
> > > >> >> > > > > > > > > > + JNIEnv *jenv = jni_native_intf;
> > > >> >> > > > > > > > > >
> > > >> >> > > > > > > > > > should be like:
> > > >> >> > > > > > > > > > - JNIEnv *jenv = (JNIEnv*)jni_native_intf;
> > > >> >> > > > > > > > > > + JNIEnv *jenv = get_jni_env(jthread_self());
> > > >> >> > > > > > > > >
> > > >> >> > > > > > > > > Ok, I see. I agree that global jni_native_intf should
> > > >> >> not be used.
> > > >> >> > > > > > > > > There was simple reason why I altered such lines.
> > > >> >> Because I changed
> > > >> >> > > > > > > > > the type of jni_native_intf and no casting operator
> > > >> >> is needed now. To
> > > >> >> > > > > > > > > be honest I think get_jni_env(jthread_self()) can be
> > > >> >> good as temporary
> > > >> >> > > > > > > > > solution only. Lets wait for design of multi VM and
> > > >> >> fix it according
> > > >> >> > > > > > > > > to it.
> > > >> >> > > > > > > >
> > > >> >> > > > > > > > While we are in JNI code, we always have the JNIenv (at
> > > >> >> least
> > > >> >> > > > > > > > initially it comes from Java code). If we consider VM
> > > >> >> code as if it
> > > >> >> > > > > > > > was a JNI application, then it seems like we should be
> > > >> >> just passing
> > > >> >> > > > > > > > JNIEnv as a parameter to all functions in VM. Or, we can
> > > >> >> be taking it
> > > >> >> > > > > > > > from TLS (via jthread_self()), depending on which way is
> > > >> >> faster...
> > > >> >> > > > > > > Agree.
> > > >> >> > > > > > >
> > > >> >> > > > > > > >
> > > >> >> > > > > > > > >
> > > >> >> > > > > > > > > >
> > > >> >> > > > > > > > > > 6). And small remarks:
> > > >> >> > > > > > > > > > +jint vm_init1(JavaVM_Internal * java_vm,
> > > >> >> JavaVMInitArgs * vm_arguments);
> > > >> >> > > > > > > > > > +jint vm_init2(JNIEnv_Internal * jni_env);
> > > >> >> > > > > > > > > > Could you make names more meaningful, then 1,2,3...?
> > > >> >> > > > > > > > > Ok, will do that.
> > > >> >> > > > > > > > >
> > > >> >> > > > > > > > > >
> > > >> >> > > > > > > > > > class VM_thread {
> > > >> >> > > > > > > > > > ...
> > > >> >> > > > > > > > > > + JNIEnv_Internal * jni_env;
> > > >> >> > > > > > > > > > The jthread already has the jni_env pointer, you do
> > > >> >> not need to
> > > >> >> > > > > > > > > > duplicate it here.
> > > >> >> > > > > > > > > > forexample by using
> > > >> >> jthread_get_JNI_env(jthread_self());
> > > >> >> > > > > > > > >
> > > >> >> > > > > > > > > Yes I know. I don't see any problems here. Some times
> > > >> >> it is much more
> > > >> >> > > > > > > > > convenient to get JNIEnv from VM_thread structure (and
> > > >> >> faster) instead
> > > >> >> > > > > > > > > of doing jthread_get_JNI_env(jthread_self()). So I
> > > >> >> need strong
> > > >> >> > > > > > > > > arguments for removing it. Again it seems that should
> > > >> >> be addressed in
> > > >> >> > > > > > > > > design of multi VM. So lets forget about it for a
> > > >> >> while...
> > > >> >> > > > > > > >
> > > >> >> > > > > > > > I think that the data duplication would always serve as
> > > >> >> a potential
> > > >> >> > > > > > > > source of errors - while updating one copy of object,
> > > >> >> you may forget
> > > >> >> > > > > > > > to update the other, often resulting into a strange
> > > >> >> behavior of the
> > > >> >> > > > > > > > whole application. Let's see what are the specific
> > > >> >> performance
> > > >> >> > > > > > > > concerns that have to be addressed. To get VM_thread
> > > >> >> structure, you
> > > >> >> > > > > > > > would eventually go to the TLS, just like
> > > >> >> > > > > > > > jthread_get_JNI_env(jthread_self() would do.
> > > >> >> > > > > > > If there is already VM_thread structure for some reasons
> > > >> >> then there
> > > >> >> > > > > > > will be no extra access to TLS. It is definitely much
> > > >> more in
> > > >> >> > > > > > > jthread_get_JNI_env(jthread_self() than just one TLS
> > > >> >> access and one
> > > >> >> > > > > > > dereferncing. I don't think it is a really big problem
> > > >> >> now. Do you
> > > >> >> > > > > > > agree to look at this later. I guess multi VM
> > > >> >> implementation will
> > > >> >> > > > > > > alter it in any case.
> > > >> >> > > > > > >
> > > >> >> > > > > > > Thanks
> > > >> >> > > > > > > Evgueni
> > > >> >> > > > > > >
> > > >> >> > > > > > > >
> > > >> >> > > > > > > > Thanks,
> > > >> >> > > > > > > > Andrey.
> > > >> >> > > > > > > >
> > > >> >> > > > > > > > >
> > > >> >> > > > > > > > > Evgueni
> > > >> >> > > > > > > > > >
> > > >> >> > > > > > > > > > Thanks
> > > >> >> > > > > > > > > > Artem
> > > >> >> > > > > > > > > >
> > > >> >> > > > > > > > > > On 9/28/06, Evgueni Brevnov
> > > >> >> <ev...@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.
> > > >> >> > > > > > > > > > >
> > > >> >> > > > > > > > > > > Thanks
> > > >> >> > > > > > > > > > > Evgueni
> > > >> >> > > > > > > > > > >
> > > >> >> > > > > > > > > > > On 9/28/06, Geir Magnusson Jr. <ge...@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
> > > >> >> <we...@gmail.com> wrote:
> > > >> >> > > > > > > > > > > > >> On 9/26/06, Evgueni Brevnov
> > > >> >> <ev...@gmail.com> wrote:
> > > >> >> > > > > > > > > > > > >> >
> > > >> >> > > > > > > > > > > > >> > On 9/27/06, Andrey Chernyshev
> > > >> >> <a....@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
> > > >> >> > > > > > > > > > >
> > > >> >> > > > > > > > > > >
> > > >> >> > > > > > > > > >
> > > >> >> > > > > > > > > >
> > > >> >> ---------------------------------------------------------------------
> > > >> >> > > > > > > > > > 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
> > > >> >> > > > > > > > >
> > > >> >> > > > > > > > >
> > > >> >> > > > > > > >
> > > >> >> > > > > > > >
> > > >> >> > > > > > > > --
> > > >> >> > > > > > > > Andrey Chernyshev
> > > >> >> > > > > > > > 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
> > > >> >> > > > > >
> > > >> >> > > > > >
> > > >> >> > > > >
> > > >> >> > > > >
> > > >> >> > > > > --
> > > >> >> > > > > Andrey Chernyshev
> > > >> >> > > > > 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
> > > >> >> > > >
> > > >> >> > > >
> > > >> >> > >
> > > >> >> > >
> > > >> >> > > --
> > > >> >> > > Andrey Chernyshev
> > > >> >> > > 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
> > > >>
> > > >>
> > > >
> > > > ---------------------------------------------------------------------
> > > > 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
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
Posted by Evgueni Brevnov <ev...@gmail.com>.
I mahaged to resolve the problem on Linux.... will update
build.final.patch with build.final.2.patch in a while
On 10/8/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> Hi,
>
> Oh! Ooh! I did that..... I passed cunit, somke, kernel tests on
> Windows and smoke, kernel tests on Linux. Unfortunately I failed to
> link cunit tests on Linux so far. So I disabled cunit on Linux until
> the problem is solved. I believe it is acceptable as short term
> solution. I found several problems in cunit tests. I will come up with
> my findings later (not today).
>
> Use latest patches from HARMONY-1582. They are marked as final. There
> are three patches. One for build module, one for cunit tests and one
> for VM itself.
>
> Thanks
> Evgueni
>
>
> On 10/6/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> > Nooooooo! LOL
> >
> > I'm here waiting - This will unblock a whole bunch of things :)
> >
> > Thanks for the effort
> >
> > Evgueni Brevnov wrote:
> > > Geir,
> > >
> > > That's terrible. We have power outage....servers are down. I can't
> > > send the patches now.... will do it tomorrow
> > >
> > > Evgueni
> > > On 10/5/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> > >> woo hoo! here we go...
> > >>
> > >>
> > >> Andrey Chernyshev wrote:
> > >> > Hi Evgueni,
> > >> >
> > >> > On 10/4/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> > >> >> Hi All,
> > >> >>
> > >> >> I have attached updated patch to the JIRA. It should resolve remain
> > >> >> concerns. Andrey, could you give a green light now?
> > >> >
> > >> > Thanks for updating the patch! I agree it it can be committed, at
> > >> > least signatures look good. 5 revisions seem like more than enough :).
> > >> > Anyways, I think the remaining issues can be resolved with additional
> > >> > patches. Thanks again for the good work and your patience.
> > >> >
> > >> > Thanks,
> > >> > Andrey.
> > >> >
> > >> >>
> > >> >> Thanks
> > >> >> Evgueni
> > >> >>
> > >> >> On 10/4/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> > >> >> > Andrey,
> > >> >> >
> > >> >> > I see your points. I think both approaches have advantages and
> > >> >> > disadvantages. I think it is quite hard to say which approach is
> > >> >> > better until we play with one VM only. I still feel like introducing
> > >> >> > one more dependence is better than spreading code which deals with
> > >> >> > attachment among VM and TM. We really get stuck. OK, just because I
> > >> >> > want to move forward I will do required changes to remove
> > >> >> > vm_create_jthread from TM. I believe that will resolve all our
> > >> >> > disagreements and the patch will be applied soon.
> > >> >> >
> > >> >> >
> > >> >> > Thanks
> > >> >> > Evgueni.
> > >> >> >
> > >> >> > On 10/4/06, Andrey Chernyshev <a....@gmail.com> wrote:
> > >> >> > > On 10/3/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> > >> >> > > > On 10/3/06, Andrey Chernyshev <a....@gmail.com> wrote:
> > >> >> > > > > On 10/2/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> > >> >> > > > > > Andrey,
> > >> >> > > > > >
> > >> >> > > > > > Just to be clear.... I agree with you it is more
> > >> convenient if
> > >> >> > > > > > jthread_create takes JNIEnv instead of JavaVM. It
> > >> reflects that
> > >> >> > > > > > current thread has been attached already. Do you think it
> > >> >> makes sense
> > >> >> > > > > > to get rid of JNIEnv and use jthread_get_JNI_env in that
> > >> case?
> > >> >> > > > >
> > >> >> > > > > The jthread_* layer is designed like if it were a regular JNI
> > >> >> > > > > application which is meant to be called from the Java code,
> > >> hence
> > >> >> > > > > every function on that layer receives JNIenv. We can probably
> > >> >> get rid
> > >> >> > > > > of the JNEnv parameter for jthread_* functions, assuming that
> > >> >> TM can
> > >> >> > > > > always extract JNIenv for the current thread with
> > >> >> > > > > jthread_get_JNI_env().
> > >> >> > > > > My only concern would be the performance - once the JNIenv is
> > >> >> already
> > >> >> > > > > known for the native part of the kernel classes impl, it
> > >> must be
> > >> >> > > > > cheaper to pass JNIEnv to TM as an extra parameter rather than
> > >> >> extract
> > >> >> > > > > it from the TLS again.
> > >> >> > > > > Other than that, I see no strong advantages in keeping JNIEnv
> > >> >> parameter.
> > >> >> > > > >
> > >> >> > > > >
> > >> >> > > > > > Regarding jthread_attach. I still didn't get your point....
> > >> >> Clarify it
> > >> >> > > > > > please if you think jhread_attach should be modified.
> > >> >> > > > >
> > >> >> > > > > Sorry for being not clear: I think for jthread_attach, we have
> > >> >> two options:
> > >> >> > > > > 1) Make JNIEnv input parameter - it must be new JNIEnv that VM
> > >> >> > > > > pre-allocates for the new Java thread. jthread_attach
> > >> would just
> > >> >> > > > > associate it with the current thread.
> > >> >> > > > >
> > >> >> > > > > 2) Obtain JNIEnv via vm_attach() callback. In this case, if
> > >> >> > > > > vm_attach() callback implementation needs to know for which
> > >> >> JavaVM new
> > >> >> > > > > JNIenv has to be allocated, then we'll need to add JavaVM as
> > >> >> input
> > >> >> > > > > parameter for jthread_attach().
> > >> >> > > > > I think both options should be fine, (1) would probably
> > >> keep TM
> > >> >> > > > > interface a bit lighter, though (2) may look more closer to
> > >> >> the JNI
> > >> >> > > > > invocation API idea.
> > >> >> > > > > So I think adding JavaVM specifically for jthread_attach
> > >> may make
> > >> >> > > > > sense given the explanation you provided earlier.
> > >> >> > > > >
> > >> >> > > > > The concern I would have regarding the proposed jthread_attach
> > >> >> > > > > implementation is a call to vm_create_jthread() - this call
> > >> >> introduces
> > >> >> > > > > an extra dependency of TM on vmcore that I'd prefer to be
> > >> >> avoided. In
> > >> >> > > > > the original version, jthread_attach() was taking jthread
> > >> >> argument of
> > >> >> > > > > the already prepared j.l.Thread.
> > >> >> > > >
> > >> >> > > > I understand your concern. Unfortunately I don't see what we
> > >> can do
> > >> >> > > > here. Let me explain. In the beginning you have an unattached
> > >> >> native
> > >> >> > > > thread. To be able to call java code (which is required for
> > >> >> > > > constructing j.l.Thread instance) the thread should be attached
> > >> >> first.
> > >> >> > > > To be specific it should be attached to VM by calling vm_attach
> > >> >> which
> > >> >> > > > will return a valid JNIEnv It is valid to use JNI from that
> > >> moment.
> > >> >> > > > Obtained JNIEnv can be used to execute java code and create
> > >> >> j.l.Thread
> > >> >> > > > instance. Since we do vm_attach in jthread_attach we need to do
> > >> >> > > > vm_create_jthread inside jthread_atach as well.
> > >> >> > > > Of course it can be an alternative to do vm_attach and
> > >> >> > > > vm_create_jthread outside of TM right before jthread_attach.
> > >> >> Sure it
> > >> >> > > > will reduce one dependence between VM and TM. But it seems like
> > >> >> > > > artificial action for me just because of dependency....
> > >> >> > >
> > >> >> > > Why do you think it is artificial? I would rather prefer not to
> > >> throw
> > >> >> > > vm_attach event from the jthread_attach() call at all than to add
> > >> >> > > extra dependency. The idea of jthread layer is a Java face to
> > >> >> > > hythread, it is meant to know either a little or nothing about the
> > >> >> > > rest of VM. It may be logical to throw vm_attach call from the
> > >> newly
> > >> >> > > created thread, because there is no other way to let know VM
> > >> the new
> > >> >> > > thread is created. VM attach is a different case - VM already
> > >> knows
> > >> >> > > about new Java thread at the time of the AttachCurrentThread call.
> > >> >> > >
> > >> >> > > >
> > >> >> > > > > Do you think it makes sense to replace a single jthread
> > >> >> parameter with
> > >> >> > > > > a variety of stuff (like thread group, name)? It seems the
> > >> only
> > >> >> > > > > purpose of at these args is to be passed back to VM for
> > >> >> > > > > vm_jthread_create(). I would suggest to change this and try
> > >> doing
> > >> >> > > > > either of:
> > >> >> > > > > 1) Make signature of jthread_attach with 3 args, JavaVM,
> > >> >> jthread and the daemon.
> > >> >> > > > Why do you want to pass daemon to TM but thread's name and
> > >> >> group. Just
> > >> >> > > > because current TM doesn't need such information? What if it is
> > >> >> > > > required to get thread name later? Say by introducing
> > >> >> > >
> > >> >> > > I imagine you need a daemon attribute since the TM is still
> > >> managing
> > >> >> > > the thread daemonality. TM is not managing thread name and group -
> > >> >> > > they are all kept on the Java level, hence passing them may be
> > >> >> > > excessive.
> > >> >> > >
> > >> >> > > > jthread_get_name... What will you do in that case? Let me
> > >> guess you
> > >> >> > > > will call j.l.Thread.getName. Right. Ok! In that case I see no
> > >> >> > > > problems to call j.l.Thread.isDaemon. Do you agree? So it
> > >> doesn't
> > >> >> > >
> > >> >> > > As I suggested earlier, the best way to handle daemonality would
> > >> >> > > probably be in pure Java - in j.l.Thread (or
> > >> j.l.VMThreadManager) or
> > >> >> > > whatever. You already lifted it up to the jthread level, but
> > >> what if
> > >> >> > > we can go a little bit higher...
> > >> >> > >
> > >> >> > > > seems to be a good design to pass only part of the
> > >> information to
> > >> >> > > > jthread_atach. Lets look at the signature of
> > >> >> AttachCurrentThread. It
> > >> >> > > > takes exactly these three parameters (daemon, name, group)
> > >> >> passed as a
> > >> >> > > > structure. I was thinking about having exactly the same
> > >> >> structure as
> > >> >> > > > third parameter of jthread_attach but it occured to be more
> > >> >> convinient
> > >> >> > > > to pass them seperatly. Although I don't see strong reasons
> > >> against
> > >> >> > > > having a structure a third parameter.
> > >> >> > >
> > >> >> > > I see. Acually, I would love to keep the jthread_attach func-ty at
> > >> >> the
> > >> >> > > minimum level which will be needed to handle the only data that TM
> > >> >> > > should be aware of. We need a formal boundary between jthread
> > >> layer
> > >> >> > > and vmcore (otherwise jthread won't have a much of sense, one may
> > >> >> > > consider it just as a convenience set of functions in vmcore which
> > >> >> are
> > >> >> > > doing something with threading).
> > >> >> > >
> > >> >> > > >
> > >> >> > > > > 2) Move the implementation of vm_create_jtrhead() to
> > >> >> > > > > thread_java_basic.c - could it be written in pure JNI without
> > >> >> using
> > >> >> > > > > internal VM API like class_alloc_new_object()?
> > >> >> > > >
> > >> >> > > > Yes, this can be done but it doesn't fix the problem. You still
> > >> >> need
> > >> >> > > > to know about internal constructor of j.l.Thread
> > >> >> > >
> > >> >> > > That's bad. Given what you said, now it seems that the most
> > >> >> preferable
> > >> >> > > sequence for AttachCurrentThread impl still would be like:
> > >> >> > > JNIEnv = vm_attach();
> > >> >> > > jthread = create_jthread(JNIenv)
> > >> >> > > jthread_attach(JNIEnv, jthread) // stores JNIEnv and Hythread into
> > >> >> > > TLS, doesn't call vm_attach any longer.
> > >> >> > > - this is almost what we had from the beginning...
> > >> >> > >
> > >> >> > > Thanks,
> > >> >> > > Andrey.
> > >> >> > >
> > >> >> > > >
> > >> >> > > >
> > >> >> > > > Thanks
> > >> >> > > > Evgueni
> > >> >> > > > >
> > >> >> > > > >
> > >> >> > > > > Thanks,
> > >> >> > > > > Andrey.
> > >> >> > > > >
> > >> >> > > > > >
> > >> >> > > > > > Thank you
> > >> >> > > > > > Evgueni
> > >> >> > > > > >
> > >> >> > > > > > On 10/2/06, Evgueni Brevnov <ev...@gmail.com>
> > >> wrote:
> > >> >> > > > > > > On 9/29/06, Andrey Chernyshev <a....@gmail.com>
> > >> >> wrote:
> > >> >> > > > > > > > On 9/29/06, Evgueni Brevnov <ev...@gmail.com>
> > >> >> wrote:
> > >> >> > > > > > > > > Artem,
> > >> >> > > > > > > > >
> > >> >> > > > > > > > > Thank you for your feedback.... find my inlined.....
> > >> >> > > > > > > > >
> > >> >> > > > > > > > > On 9/29/06, Artem Aliev <ar...@gmail.com> wrote:
> > >> >> > > > > > > > > > Evgueni,
> > >> >> > > > > > > > > >
> > >> >> > > > > > > > > > I got most of your changes, but still disagree
> > >> with all
> > >> >> > > > > > > > > > hythread/jthread interface changes. Could leave
> > >> >> interface unchanged.
> > >> >> > > > > > > > > > See following possible solutions, that could solve
> > >> >> the same problems
> > >> >> > > > > > > > > > without interface changes.
> > >> >> > > > > > > > > >
> > >> >> > > > > > > > > >
> > >> >> > > > > > > > > > 1) daemon attribute is a java specific. (Andrey
> > >> >> mentioned this already).
> > >> >> > > > > > > > > > Could you please move it back. to the jthread
> > >> >> layer. It is better
> > >> >> > > > > > > > > > to rename
> > >> >> > > > > > > > > > hythread_wait_for_all_nondaemon_threads() to
> > >> >> > > > > > > > > > jthread_wait_for_all_nondaemon_threads().
> > >> >> > > > > > > > > Ok, I see no problems to move "daemon" to java layer.
> > >> >> In that case:
> > >> >> > > > > > > > > 1) I will move
> > >> >> hythread_wait_for_all_nondaemon_threads() from
> > >> >> > > > > > > > > thread_init.c to one which implements java layer.
> > >> >> > > > > > > > > 2) I will move daemon field from HyThread structure.
> > >> >> > > > > > > > >
> > >> >> > > > > > > > > Agree?
> > >> >> > > > > > > >
> > >> >> > > > > > > > Sounds good to me.
> > >> >> > > > > > >
> > >> >> > > > > > > OK, will do that.
> > >> >> > > > > > >
> > >> >> > > > > > > >
> > >> >> > > > > > > >
> > >> >> > > > > > > > >
> > >> >> > > > > > > > > >
> > >> >> > > > > > > > > > 2) JavaVM could be retrieved from JNIEnv by
> > >> >> jni_get_java_vm(). So
> > >> >> > > > > > > > > > let the jthread_create() and others to use JNIEnv
> > >> >> (that is passed from
> > >> >> > > > > > > > > > java native method).
> > >> >> > > > > > > > > > The vm_attach could get old JNI env and create new
> > >> >> one for the new thread.
> > >> >> > > > > > > > > > The first JNIEnv is created in CreateVM call and
> > >> >> could be passed to
> > >> >> > > > > > > > > > the first thread at startup.
> > >> >> > > > > > > > > No, no, no. I completely disagree with that!!! Why do
> > >> >> you like JNIEnv
> > >> >> > > > > > > > > but JavaVM. Why do you think that passing JavaVM
> > >> >> instead of JNIEnv
> > >> >> > > > > > > > > makes TM less modular? I don't see any difference
> > >> >> here.... It seems
> > >> >> > > > > > > > > for me like a big big hack to grab JNIEnv from another
> > >> >> thread and pass
> > >> >> > > > > > > > > it to jthread_attach to perform operations in the
> > >> >> current thread.
> > >> >> > > > > > > >
> > >> >> > > > > > > > TM needs to know JNIEnv, mainly for managing the
> > >> >> references to
> > >> >> > > > > > > > objects, throwing exceptions and calling run() method of
> > >> >> a new thread.
> > >> >> > > > > > > > JNI spec proposes that JNIEnv is valid within the given
> > >> >> thread, this
> > >> >> > > > > > > > is why TM holds the JNIEnv pointer at the moment. This
> > >> >> is why TM likes
> > >> >> > > > > > > > the JNIEnv.
> > >> >> > > > > > > >
> > >> >> > > > > > > > Having the JNIEnv, one is able to get JavaVM but not
> > >> >> vise versa. This
> > >> >> > > > > > > > is why TM doesn't like the JavaVM :)
> > >> >> > > > > > > I see your point. Only one note this is true for already
> > >> >> attached threads...
> > >> >> > > > > > >
> > >> >> > > > > > > >
> > >> >> > > > > > > > I agree with you that there is a design flaw that the
> > >> >> JNIEnv is copied
> > >> >> > > > > > > > from the parent thread to a child thread during thread
> > >> >> creation. I
> > >> >> > > > > > > > think it could be resolved via vm_attach() hook - with
> > >> >> this event, VM
> > >> >> > > > > > > > might tell the TM what the JNIEnv pointer for new thread
> > >> >> should be. I
> > >> >> > > > > > > > think you did that by extending the vm_attach() call
> > >> >> with the JNIEnv**
> > >> >> > > > > > > > argument.
> > >> >> > > > > > > >
> > >> >> > > > > > > > What is not completely clear is, why do you have to pass
> > >> >> the JavaVM
> > >> >> > > > > > > > forth and back, once from VM to TM, and then back from
> > >> >> TM to VM again?
> > >> >> > > > > > > >
> > >> >> > > > > > > > If you need to know in jthread_attach, which particular
> > >> >> VM vm_attach()
> > >> >> > > > > > > > event is coming from, you could have vm_attach like
> > >> >> > > > > > > > vm_attach(JNIEnv* currentThreadEnv, JNIEnv**
> > >> >> newThreadEnv).
> > >> >> > > > > > > I'm a little bit confused.....Current thread hasn't been
> > >> >> attached yet.
> > >> >> > > > > > > So there is no JNIEnv for it yet. How it can be passed as
> > >> >> the first
> > >> >> > > > > > > parameter to vm_attach()?
> > >> >> > > > > > >
> > >> >> > > > > > > > Then you will be always able to get the JavaVM from the
> > >> >> JNIEnv.
> > >> >> > > > > > > > The only difference is that you are currently doing
> > >> >> JNIEnv->JavaVM
> > >> >> > > > > > > > conversion in the VMThreadManager, but why can't you
> > >> >> just do this in
> > >> >> > > > > > > > vm_attach() without changing the interface of the TM?
> > >> >> > > > > > > > So far JavaVM really looks like an extra knowledge that
> > >> >> TM doesn't
> > >> >> > > > > > > > have to be aware of.
> > >> >> > > > > > > >
> > >> >> > > > > > > > > Moreover there is no JNIEnv when main thread attaches
> > >> >> to VM. So we
> > >> >> > > > > > > > > should either keep it as is or change original design
> > >> >> of TM and attach
> > >> >> > > > > > > > > thread to VM before attaching it to TM. In that case
> > >> >> we will have
> > >> >> > > > > > > > > valid JNIEnv which can be passed to jthread_atatch. We
> > >> >> need to think
> > >> >> > > > > > > > > over it twice before changing something....
> > >> >> > > > > > > >
> > >> >> > > > > > > > Right. For jthread_attach, JNIenv needs to be changed
> > >> >> from being input
> > >> >> > > > > > > > parameter to being the output parameter. The way how
> > >> >> JNIenv is
> > >> >> > > > > > > > obtained by TM should be vm_attach() event.
> > >> >> > > > > > > OK, JNIEnv is output parameter. And it obtained by
> > >> >> vm_attach(). This
> > >> >> > > > > > > is exactly like I do in the patch. What I don't understand
> > >> >> is how
> > >> >> > > > > > > jthread_attach knows to which VM the thread should be
> > >> >> attached? Do you
> > >> >> > > > > > > suggest calling vm_attach first to create JNIEnv it pass
> > >> >> it to
> > >> >> > > > > > > jthread_attach?
> > >> >> > > > > > >
> > >> >> > > > > > > >
> > >> >> > > > > > > > >
> > >> >> > > > > > > > >
> > >> >> > > > > > > > >
> > >> >> > > > > > > > > >
> > >> >> > > > > > > > > >
> > >> >> > > > > > > > > > 4) Original classlib hythread do not use
> > >> >> hythread_library_t in arguments,
> > >> >> > > > > > > > > > It uses following code:
> > >> >> > > > > > > > > >
> > >> >> > > > > > > > > > hythread_library_t lib = GLOBAL_DATA
> > >> >> (default_library);
> > >> >> > > > > > > > > > or
> > >> >> > > > > > > > > > hythread_library_t library = thread->library;
> > >> >> > > > > > > > > >
> > >> >> > > > > > > > > > So could you please use the same mechanism and
> > >> >> remove hythread_*_ex >functions.
> > >> >> > > > > > > > > Let's see if classlib's hythread needs changing first.
> > >> >> It seems for me
> > >> >> > > > > > > > > such code prevents us from having multi VM.
> > >> >> > > > > > > > >
> > >> >> > > > > > > > > >
> > >> >> > > > > > > > > > 5. You introduce more then one jni env, but still
> > >> >> use global variable for it.
> > >> >> > > > > > > > > > So all changes like following:
> > >> >> > > > > > > > > > - JNIEnv *jenv = (JNIEnv*)jni_native_intf;
> > >> >> > > > > > > > > > + JNIEnv *jenv = jni_native_intf;
> > >> >> > > > > > > > > >
> > >> >> > > > > > > > > > should be like:
> > >> >> > > > > > > > > > - JNIEnv *jenv = (JNIEnv*)jni_native_intf;
> > >> >> > > > > > > > > > + JNIEnv *jenv = get_jni_env(jthread_self());
> > >> >> > > > > > > > >
> > >> >> > > > > > > > > Ok, I see. I agree that global jni_native_intf should
> > >> >> not be used.
> > >> >> > > > > > > > > There was simple reason why I altered such lines.
> > >> >> Because I changed
> > >> >> > > > > > > > > the type of jni_native_intf and no casting operator
> > >> >> is needed now. To
> > >> >> > > > > > > > > be honest I think get_jni_env(jthread_self()) can be
> > >> >> good as temporary
> > >> >> > > > > > > > > solution only. Lets wait for design of multi VM and
> > >> >> fix it according
> > >> >> > > > > > > > > to it.
> > >> >> > > > > > > >
> > >> >> > > > > > > > While we are in JNI code, we always have the JNIenv (at
> > >> >> least
> > >> >> > > > > > > > initially it comes from Java code). If we consider VM
> > >> >> code as if it
> > >> >> > > > > > > > was a JNI application, then it seems like we should be
> > >> >> just passing
> > >> >> > > > > > > > JNIEnv as a parameter to all functions in VM. Or, we can
> > >> >> be taking it
> > >> >> > > > > > > > from TLS (via jthread_self()), depending on which way is
> > >> >> faster...
> > >> >> > > > > > > Agree.
> > >> >> > > > > > >
> > >> >> > > > > > > >
> > >> >> > > > > > > > >
> > >> >> > > > > > > > > >
> > >> >> > > > > > > > > > 6). And small remarks:
> > >> >> > > > > > > > > > +jint vm_init1(JavaVM_Internal * java_vm,
> > >> >> JavaVMInitArgs * vm_arguments);
> > >> >> > > > > > > > > > +jint vm_init2(JNIEnv_Internal * jni_env);
> > >> >> > > > > > > > > > Could you make names more meaningful, then 1,2,3...?
> > >> >> > > > > > > > > Ok, will do that.
> > >> >> > > > > > > > >
> > >> >> > > > > > > > > >
> > >> >> > > > > > > > > > class VM_thread {
> > >> >> > > > > > > > > > ...
> > >> >> > > > > > > > > > + JNIEnv_Internal * jni_env;
> > >> >> > > > > > > > > > The jthread already has the jni_env pointer, you do
> > >> >> not need to
> > >> >> > > > > > > > > > duplicate it here.
> > >> >> > > > > > > > > > forexample by using
> > >> >> jthread_get_JNI_env(jthread_self());
> > >> >> > > > > > > > >
> > >> >> > > > > > > > > Yes I know. I don't see any problems here. Some times
> > >> >> it is much more
> > >> >> > > > > > > > > convenient to get JNIEnv from VM_thread structure (and
> > >> >> faster) instead
> > >> >> > > > > > > > > of doing jthread_get_JNI_env(jthread_self()). So I
> > >> >> need strong
> > >> >> > > > > > > > > arguments for removing it. Again it seems that should
> > >> >> be addressed in
> > >> >> > > > > > > > > design of multi VM. So lets forget about it for a
> > >> >> while...
> > >> >> > > > > > > >
> > >> >> > > > > > > > I think that the data duplication would always serve as
> > >> >> a potential
> > >> >> > > > > > > > source of errors - while updating one copy of object,
> > >> >> you may forget
> > >> >> > > > > > > > to update the other, often resulting into a strange
> > >> >> behavior of the
> > >> >> > > > > > > > whole application. Let's see what are the specific
> > >> >> performance
> > >> >> > > > > > > > concerns that have to be addressed. To get VM_thread
> > >> >> structure, you
> > >> >> > > > > > > > would eventually go to the TLS, just like
> > >> >> > > > > > > > jthread_get_JNI_env(jthread_self() would do.
> > >> >> > > > > > > If there is already VM_thread structure for some reasons
> > >> >> then there
> > >> >> > > > > > > will be no extra access to TLS. It is definitely much
> > >> more in
> > >> >> > > > > > > jthread_get_JNI_env(jthread_self() than just one TLS
> > >> >> access and one
> > >> >> > > > > > > dereferncing. I don't think it is a really big problem
> > >> >> now. Do you
> > >> >> > > > > > > agree to look at this later. I guess multi VM
> > >> >> implementation will
> > >> >> > > > > > > alter it in any case.
> > >> >> > > > > > >
> > >> >> > > > > > > Thanks
> > >> >> > > > > > > Evgueni
> > >> >> > > > > > >
> > >> >> > > > > > > >
> > >> >> > > > > > > > Thanks,
> > >> >> > > > > > > > Andrey.
> > >> >> > > > > > > >
> > >> >> > > > > > > > >
> > >> >> > > > > > > > > Evgueni
> > >> >> > > > > > > > > >
> > >> >> > > > > > > > > > Thanks
> > >> >> > > > > > > > > > Artem
> > >> >> > > > > > > > > >
> > >> >> > > > > > > > > > On 9/28/06, Evgueni Brevnov
> > >> >> <ev...@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.
> > >> >> > > > > > > > > > >
> > >> >> > > > > > > > > > > Thanks
> > >> >> > > > > > > > > > > Evgueni
> > >> >> > > > > > > > > > >
> > >> >> > > > > > > > > > > On 9/28/06, Geir Magnusson Jr. <ge...@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
> > >> >> <we...@gmail.com> wrote:
> > >> >> > > > > > > > > > > > >> On 9/26/06, Evgueni Brevnov
> > >> >> <ev...@gmail.com> wrote:
> > >> >> > > > > > > > > > > > >> >
> > >> >> > > > > > > > > > > > >> > On 9/27/06, Andrey Chernyshev
> > >> >> <a....@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
> > >> >> > > > > > > > > > >
> > >> >> > > > > > > > > > >
> > >> >> > > > > > > > > >
> > >> >> > > > > > > > > >
> > >> >> ---------------------------------------------------------------------
> > >> >> > > > > > > > > > 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
> > >> >> > > > > > > > >
> > >> >> > > > > > > > >
> > >> >> > > > > > > >
> > >> >> > > > > > > >
> > >> >> > > > > > > > --
> > >> >> > > > > > > > Andrey Chernyshev
> > >> >> > > > > > > > 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
> > >> >> > > > > >
> > >> >> > > > > >
> > >> >> > > > >
> > >> >> > > > >
> > >> >> > > > > --
> > >> >> > > > > Andrey Chernyshev
> > >> >> > > > > 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
> > >> >> > > >
> > >> >> > > >
> > >> >> > >
> > >> >> > >
> > >> >> > > --
> > >> >> > > Andrey Chernyshev
> > >> >> > > 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
> > >>
> > >>
> > >
> > > ---------------------------------------------------------------------
> > > 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
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
Posted by Evgueni Brevnov <ev...@gmail.com>.
Hi,
Oh! Ooh! I did that..... I passed cunit, somke, kernel tests on
Windows and smoke, kernel tests on Linux. Unfortunately I failed to
link cunit tests on Linux so far. So I disabled cunit on Linux until
the problem is solved. I believe it is acceptable as short term
solution. I found several problems in cunit tests. I will come up with
my findings later (not today).
Use latest patches from HARMONY-1582. They are marked as final. There
are three patches. One for build module, one for cunit tests and one
for VM itself.
Thanks
Evgueni
On 10/6/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> Nooooooo! LOL
>
> I'm here waiting - This will unblock a whole bunch of things :)
>
> Thanks for the effort
>
> Evgueni Brevnov wrote:
> > Geir,
> >
> > That's terrible. We have power outage....servers are down. I can't
> > send the patches now.... will do it tomorrow
> >
> > Evgueni
> > On 10/5/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> >> woo hoo! here we go...
> >>
> >>
> >> Andrey Chernyshev wrote:
> >> > Hi Evgueni,
> >> >
> >> > On 10/4/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> >> >> Hi All,
> >> >>
> >> >> I have attached updated patch to the JIRA. It should resolve remain
> >> >> concerns. Andrey, could you give a green light now?
> >> >
> >> > Thanks for updating the patch! I agree it it can be committed, at
> >> > least signatures look good. 5 revisions seem like more than enough :).
> >> > Anyways, I think the remaining issues can be resolved with additional
> >> > patches. Thanks again for the good work and your patience.
> >> >
> >> > Thanks,
> >> > Andrey.
> >> >
> >> >>
> >> >> Thanks
> >> >> Evgueni
> >> >>
> >> >> On 10/4/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> >> >> > Andrey,
> >> >> >
> >> >> > I see your points. I think both approaches have advantages and
> >> >> > disadvantages. I think it is quite hard to say which approach is
> >> >> > better until we play with one VM only. I still feel like introducing
> >> >> > one more dependence is better than spreading code which deals with
> >> >> > attachment among VM and TM. We really get stuck. OK, just because I
> >> >> > want to move forward I will do required changes to remove
> >> >> > vm_create_jthread from TM. I believe that will resolve all our
> >> >> > disagreements and the patch will be applied soon.
> >> >> >
> >> >> >
> >> >> > Thanks
> >> >> > Evgueni.
> >> >> >
> >> >> > On 10/4/06, Andrey Chernyshev <a....@gmail.com> wrote:
> >> >> > > On 10/3/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> >> >> > > > On 10/3/06, Andrey Chernyshev <a....@gmail.com> wrote:
> >> >> > > > > On 10/2/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> >> >> > > > > > Andrey,
> >> >> > > > > >
> >> >> > > > > > Just to be clear.... I agree with you it is more
> >> convenient if
> >> >> > > > > > jthread_create takes JNIEnv instead of JavaVM. It
> >> reflects that
> >> >> > > > > > current thread has been attached already. Do you think it
> >> >> makes sense
> >> >> > > > > > to get rid of JNIEnv and use jthread_get_JNI_env in that
> >> case?
> >> >> > > > >
> >> >> > > > > The jthread_* layer is designed like if it were a regular JNI
> >> >> > > > > application which is meant to be called from the Java code,
> >> hence
> >> >> > > > > every function on that layer receives JNIenv. We can probably
> >> >> get rid
> >> >> > > > > of the JNEnv parameter for jthread_* functions, assuming that
> >> >> TM can
> >> >> > > > > always extract JNIenv for the current thread with
> >> >> > > > > jthread_get_JNI_env().
> >> >> > > > > My only concern would be the performance - once the JNIenv is
> >> >> already
> >> >> > > > > known for the native part of the kernel classes impl, it
> >> must be
> >> >> > > > > cheaper to pass JNIEnv to TM as an extra parameter rather than
> >> >> extract
> >> >> > > > > it from the TLS again.
> >> >> > > > > Other than that, I see no strong advantages in keeping JNIEnv
> >> >> parameter.
> >> >> > > > >
> >> >> > > > >
> >> >> > > > > > Regarding jthread_attach. I still didn't get your point....
> >> >> Clarify it
> >> >> > > > > > please if you think jhread_attach should be modified.
> >> >> > > > >
> >> >> > > > > Sorry for being not clear: I think for jthread_attach, we have
> >> >> two options:
> >> >> > > > > 1) Make JNIEnv input parameter - it must be new JNIEnv that VM
> >> >> > > > > pre-allocates for the new Java thread. jthread_attach
> >> would just
> >> >> > > > > associate it with the current thread.
> >> >> > > > >
> >> >> > > > > 2) Obtain JNIEnv via vm_attach() callback. In this case, if
> >> >> > > > > vm_attach() callback implementation needs to know for which
> >> >> JavaVM new
> >> >> > > > > JNIenv has to be allocated, then we'll need to add JavaVM as
> >> >> input
> >> >> > > > > parameter for jthread_attach().
> >> >> > > > > I think both options should be fine, (1) would probably
> >> keep TM
> >> >> > > > > interface a bit lighter, though (2) may look more closer to
> >> >> the JNI
> >> >> > > > > invocation API idea.
> >> >> > > > > So I think adding JavaVM specifically for jthread_attach
> >> may make
> >> >> > > > > sense given the explanation you provided earlier.
> >> >> > > > >
> >> >> > > > > The concern I would have regarding the proposed jthread_attach
> >> >> > > > > implementation is a call to vm_create_jthread() - this call
> >> >> introduces
> >> >> > > > > an extra dependency of TM on vmcore that I'd prefer to be
> >> >> avoided. In
> >> >> > > > > the original version, jthread_attach() was taking jthread
> >> >> argument of
> >> >> > > > > the already prepared j.l.Thread.
> >> >> > > >
> >> >> > > > I understand your concern. Unfortunately I don't see what we
> >> can do
> >> >> > > > here. Let me explain. In the beginning you have an unattached
> >> >> native
> >> >> > > > thread. To be able to call java code (which is required for
> >> >> > > > constructing j.l.Thread instance) the thread should be attached
> >> >> first.
> >> >> > > > To be specific it should be attached to VM by calling vm_attach
> >> >> which
> >> >> > > > will return a valid JNIEnv It is valid to use JNI from that
> >> moment.
> >> >> > > > Obtained JNIEnv can be used to execute java code and create
> >> >> j.l.Thread
> >> >> > > > instance. Since we do vm_attach in jthread_attach we need to do
> >> >> > > > vm_create_jthread inside jthread_atach as well.
> >> >> > > > Of course it can be an alternative to do vm_attach and
> >> >> > > > vm_create_jthread outside of TM right before jthread_attach.
> >> >> Sure it
> >> >> > > > will reduce one dependence between VM and TM. But it seems like
> >> >> > > > artificial action for me just because of dependency....
> >> >> > >
> >> >> > > Why do you think it is artificial? I would rather prefer not to
> >> throw
> >> >> > > vm_attach event from the jthread_attach() call at all than to add
> >> >> > > extra dependency. The idea of jthread layer is a Java face to
> >> >> > > hythread, it is meant to know either a little or nothing about the
> >> >> > > rest of VM. It may be logical to throw vm_attach call from the
> >> newly
> >> >> > > created thread, because there is no other way to let know VM
> >> the new
> >> >> > > thread is created. VM attach is a different case - VM already
> >> knows
> >> >> > > about new Java thread at the time of the AttachCurrentThread call.
> >> >> > >
> >> >> > > >
> >> >> > > > > Do you think it makes sense to replace a single jthread
> >> >> parameter with
> >> >> > > > > a variety of stuff (like thread group, name)? It seems the
> >> only
> >> >> > > > > purpose of at these args is to be passed back to VM for
> >> >> > > > > vm_jthread_create(). I would suggest to change this and try
> >> doing
> >> >> > > > > either of:
> >> >> > > > > 1) Make signature of jthread_attach with 3 args, JavaVM,
> >> >> jthread and the daemon.
> >> >> > > > Why do you want to pass daemon to TM but thread's name and
> >> >> group. Just
> >> >> > > > because current TM doesn't need such information? What if it is
> >> >> > > > required to get thread name later? Say by introducing
> >> >> > >
> >> >> > > I imagine you need a daemon attribute since the TM is still
> >> managing
> >> >> > > the thread daemonality. TM is not managing thread name and group -
> >> >> > > they are all kept on the Java level, hence passing them may be
> >> >> > > excessive.
> >> >> > >
> >> >> > > > jthread_get_name... What will you do in that case? Let me
> >> guess you
> >> >> > > > will call j.l.Thread.getName. Right. Ok! In that case I see no
> >> >> > > > problems to call j.l.Thread.isDaemon. Do you agree? So it
> >> doesn't
> >> >> > >
> >> >> > > As I suggested earlier, the best way to handle daemonality would
> >> >> > > probably be in pure Java - in j.l.Thread (or
> >> j.l.VMThreadManager) or
> >> >> > > whatever. You already lifted it up to the jthread level, but
> >> what if
> >> >> > > we can go a little bit higher...
> >> >> > >
> >> >> > > > seems to be a good design to pass only part of the
> >> information to
> >> >> > > > jthread_atach. Lets look at the signature of
> >> >> AttachCurrentThread. It
> >> >> > > > takes exactly these three parameters (daemon, name, group)
> >> >> passed as a
> >> >> > > > structure. I was thinking about having exactly the same
> >> >> structure as
> >> >> > > > third parameter of jthread_attach but it occured to be more
> >> >> convinient
> >> >> > > > to pass them seperatly. Although I don't see strong reasons
> >> against
> >> >> > > > having a structure a third parameter.
> >> >> > >
> >> >> > > I see. Acually, I would love to keep the jthread_attach func-ty at
> >> >> the
> >> >> > > minimum level which will be needed to handle the only data that TM
> >> >> > > should be aware of. We need a formal boundary between jthread
> >> layer
> >> >> > > and vmcore (otherwise jthread won't have a much of sense, one may
> >> >> > > consider it just as a convenience set of functions in vmcore which
> >> >> are
> >> >> > > doing something with threading).
> >> >> > >
> >> >> > > >
> >> >> > > > > 2) Move the implementation of vm_create_jtrhead() to
> >> >> > > > > thread_java_basic.c - could it be written in pure JNI without
> >> >> using
> >> >> > > > > internal VM API like class_alloc_new_object()?
> >> >> > > >
> >> >> > > > Yes, this can be done but it doesn't fix the problem. You still
> >> >> need
> >> >> > > > to know about internal constructor of j.l.Thread
> >> >> > >
> >> >> > > That's bad. Given what you said, now it seems that the most
> >> >> preferable
> >> >> > > sequence for AttachCurrentThread impl still would be like:
> >> >> > > JNIEnv = vm_attach();
> >> >> > > jthread = create_jthread(JNIenv)
> >> >> > > jthread_attach(JNIEnv, jthread) // stores JNIEnv and Hythread into
> >> >> > > TLS, doesn't call vm_attach any longer.
> >> >> > > - this is almost what we had from the beginning...
> >> >> > >
> >> >> > > Thanks,
> >> >> > > Andrey.
> >> >> > >
> >> >> > > >
> >> >> > > >
> >> >> > > > Thanks
> >> >> > > > Evgueni
> >> >> > > > >
> >> >> > > > >
> >> >> > > > > Thanks,
> >> >> > > > > Andrey.
> >> >> > > > >
> >> >> > > > > >
> >> >> > > > > > Thank you
> >> >> > > > > > Evgueni
> >> >> > > > > >
> >> >> > > > > > On 10/2/06, Evgueni Brevnov <ev...@gmail.com>
> >> wrote:
> >> >> > > > > > > On 9/29/06, Andrey Chernyshev <a....@gmail.com>
> >> >> wrote:
> >> >> > > > > > > > On 9/29/06, Evgueni Brevnov <ev...@gmail.com>
> >> >> wrote:
> >> >> > > > > > > > > Artem,
> >> >> > > > > > > > >
> >> >> > > > > > > > > Thank you for your feedback.... find my inlined.....
> >> >> > > > > > > > >
> >> >> > > > > > > > > On 9/29/06, Artem Aliev <ar...@gmail.com> wrote:
> >> >> > > > > > > > > > Evgueni,
> >> >> > > > > > > > > >
> >> >> > > > > > > > > > I got most of your changes, but still disagree
> >> with all
> >> >> > > > > > > > > > hythread/jthread interface changes. Could leave
> >> >> interface unchanged.
> >> >> > > > > > > > > > See following possible solutions, that could solve
> >> >> the same problems
> >> >> > > > > > > > > > without interface changes.
> >> >> > > > > > > > > >
> >> >> > > > > > > > > >
> >> >> > > > > > > > > > 1) daemon attribute is a java specific. (Andrey
> >> >> mentioned this already).
> >> >> > > > > > > > > > Could you please move it back. to the jthread
> >> >> layer. It is better
> >> >> > > > > > > > > > to rename
> >> >> > > > > > > > > > hythread_wait_for_all_nondaemon_threads() to
> >> >> > > > > > > > > > jthread_wait_for_all_nondaemon_threads().
> >> >> > > > > > > > > Ok, I see no problems to move "daemon" to java layer.
> >> >> In that case:
> >> >> > > > > > > > > 1) I will move
> >> >> hythread_wait_for_all_nondaemon_threads() from
> >> >> > > > > > > > > thread_init.c to one which implements java layer.
> >> >> > > > > > > > > 2) I will move daemon field from HyThread structure.
> >> >> > > > > > > > >
> >> >> > > > > > > > > Agree?
> >> >> > > > > > > >
> >> >> > > > > > > > Sounds good to me.
> >> >> > > > > > >
> >> >> > > > > > > OK, will do that.
> >> >> > > > > > >
> >> >> > > > > > > >
> >> >> > > > > > > >
> >> >> > > > > > > > >
> >> >> > > > > > > > > >
> >> >> > > > > > > > > > 2) JavaVM could be retrieved from JNIEnv by
> >> >> jni_get_java_vm(). So
> >> >> > > > > > > > > > let the jthread_create() and others to use JNIEnv
> >> >> (that is passed from
> >> >> > > > > > > > > > java native method).
> >> >> > > > > > > > > > The vm_attach could get old JNI env and create new
> >> >> one for the new thread.
> >> >> > > > > > > > > > The first JNIEnv is created in CreateVM call and
> >> >> could be passed to
> >> >> > > > > > > > > > the first thread at startup.
> >> >> > > > > > > > > No, no, no. I completely disagree with that!!! Why do
> >> >> you like JNIEnv
> >> >> > > > > > > > > but JavaVM. Why do you think that passing JavaVM
> >> >> instead of JNIEnv
> >> >> > > > > > > > > makes TM less modular? I don't see any difference
> >> >> here.... It seems
> >> >> > > > > > > > > for me like a big big hack to grab JNIEnv from another
> >> >> thread and pass
> >> >> > > > > > > > > it to jthread_attach to perform operations in the
> >> >> current thread.
> >> >> > > > > > > >
> >> >> > > > > > > > TM needs to know JNIEnv, mainly for managing the
> >> >> references to
> >> >> > > > > > > > objects, throwing exceptions and calling run() method of
> >> >> a new thread.
> >> >> > > > > > > > JNI spec proposes that JNIEnv is valid within the given
> >> >> thread, this
> >> >> > > > > > > > is why TM holds the JNIEnv pointer at the moment. This
> >> >> is why TM likes
> >> >> > > > > > > > the JNIEnv.
> >> >> > > > > > > >
> >> >> > > > > > > > Having the JNIEnv, one is able to get JavaVM but not
> >> >> vise versa. This
> >> >> > > > > > > > is why TM doesn't like the JavaVM :)
> >> >> > > > > > > I see your point. Only one note this is true for already
> >> >> attached threads...
> >> >> > > > > > >
> >> >> > > > > > > >
> >> >> > > > > > > > I agree with you that there is a design flaw that the
> >> >> JNIEnv is copied
> >> >> > > > > > > > from the parent thread to a child thread during thread
> >> >> creation. I
> >> >> > > > > > > > think it could be resolved via vm_attach() hook - with
> >> >> this event, VM
> >> >> > > > > > > > might tell the TM what the JNIEnv pointer for new thread
> >> >> should be. I
> >> >> > > > > > > > think you did that by extending the vm_attach() call
> >> >> with the JNIEnv**
> >> >> > > > > > > > argument.
> >> >> > > > > > > >
> >> >> > > > > > > > What is not completely clear is, why do you have to pass
> >> >> the JavaVM
> >> >> > > > > > > > forth and back, once from VM to TM, and then back from
> >> >> TM to VM again?
> >> >> > > > > > > >
> >> >> > > > > > > > If you need to know in jthread_attach, which particular
> >> >> VM vm_attach()
> >> >> > > > > > > > event is coming from, you could have vm_attach like
> >> >> > > > > > > > vm_attach(JNIEnv* currentThreadEnv, JNIEnv**
> >> >> newThreadEnv).
> >> >> > > > > > > I'm a little bit confused.....Current thread hasn't been
> >> >> attached yet.
> >> >> > > > > > > So there is no JNIEnv for it yet. How it can be passed as
> >> >> the first
> >> >> > > > > > > parameter to vm_attach()?
> >> >> > > > > > >
> >> >> > > > > > > > Then you will be always able to get the JavaVM from the
> >> >> JNIEnv.
> >> >> > > > > > > > The only difference is that you are currently doing
> >> >> JNIEnv->JavaVM
> >> >> > > > > > > > conversion in the VMThreadManager, but why can't you
> >> >> just do this in
> >> >> > > > > > > > vm_attach() without changing the interface of the TM?
> >> >> > > > > > > > So far JavaVM really looks like an extra knowledge that
> >> >> TM doesn't
> >> >> > > > > > > > have to be aware of.
> >> >> > > > > > > >
> >> >> > > > > > > > > Moreover there is no JNIEnv when main thread attaches
> >> >> to VM. So we
> >> >> > > > > > > > > should either keep it as is or change original design
> >> >> of TM and attach
> >> >> > > > > > > > > thread to VM before attaching it to TM. In that case
> >> >> we will have
> >> >> > > > > > > > > valid JNIEnv which can be passed to jthread_atatch. We
> >> >> need to think
> >> >> > > > > > > > > over it twice before changing something....
> >> >> > > > > > > >
> >> >> > > > > > > > Right. For jthread_attach, JNIenv needs to be changed
> >> >> from being input
> >> >> > > > > > > > parameter to being the output parameter. The way how
> >> >> JNIenv is
> >> >> > > > > > > > obtained by TM should be vm_attach() event.
> >> >> > > > > > > OK, JNIEnv is output parameter. And it obtained by
> >> >> vm_attach(). This
> >> >> > > > > > > is exactly like I do in the patch. What I don't understand
> >> >> is how
> >> >> > > > > > > jthread_attach knows to which VM the thread should be
> >> >> attached? Do you
> >> >> > > > > > > suggest calling vm_attach first to create JNIEnv it pass
> >> >> it to
> >> >> > > > > > > jthread_attach?
> >> >> > > > > > >
> >> >> > > > > > > >
> >> >> > > > > > > > >
> >> >> > > > > > > > >
> >> >> > > > > > > > >
> >> >> > > > > > > > > >
> >> >> > > > > > > > > >
> >> >> > > > > > > > > > 4) Original classlib hythread do not use
> >> >> hythread_library_t in arguments,
> >> >> > > > > > > > > > It uses following code:
> >> >> > > > > > > > > >
> >> >> > > > > > > > > > hythread_library_t lib = GLOBAL_DATA
> >> >> (default_library);
> >> >> > > > > > > > > > or
> >> >> > > > > > > > > > hythread_library_t library = thread->library;
> >> >> > > > > > > > > >
> >> >> > > > > > > > > > So could you please use the same mechanism and
> >> >> remove hythread_*_ex >functions.
> >> >> > > > > > > > > Let's see if classlib's hythread needs changing first.
> >> >> It seems for me
> >> >> > > > > > > > > such code prevents us from having multi VM.
> >> >> > > > > > > > >
> >> >> > > > > > > > > >
> >> >> > > > > > > > > > 5. You introduce more then one jni env, but still
> >> >> use global variable for it.
> >> >> > > > > > > > > > So all changes like following:
> >> >> > > > > > > > > > - JNIEnv *jenv = (JNIEnv*)jni_native_intf;
> >> >> > > > > > > > > > + JNIEnv *jenv = jni_native_intf;
> >> >> > > > > > > > > >
> >> >> > > > > > > > > > should be like:
> >> >> > > > > > > > > > - JNIEnv *jenv = (JNIEnv*)jni_native_intf;
> >> >> > > > > > > > > > + JNIEnv *jenv = get_jni_env(jthread_self());
> >> >> > > > > > > > >
> >> >> > > > > > > > > Ok, I see. I agree that global jni_native_intf should
> >> >> not be used.
> >> >> > > > > > > > > There was simple reason why I altered such lines.
> >> >> Because I changed
> >> >> > > > > > > > > the type of jni_native_intf and no casting operator
> >> >> is needed now. To
> >> >> > > > > > > > > be honest I think get_jni_env(jthread_self()) can be
> >> >> good as temporary
> >> >> > > > > > > > > solution only. Lets wait for design of multi VM and
> >> >> fix it according
> >> >> > > > > > > > > to it.
> >> >> > > > > > > >
> >> >> > > > > > > > While we are in JNI code, we always have the JNIenv (at
> >> >> least
> >> >> > > > > > > > initially it comes from Java code). If we consider VM
> >> >> code as if it
> >> >> > > > > > > > was a JNI application, then it seems like we should be
> >> >> just passing
> >> >> > > > > > > > JNIEnv as a parameter to all functions in VM. Or, we can
> >> >> be taking it
> >> >> > > > > > > > from TLS (via jthread_self()), depending on which way is
> >> >> faster...
> >> >> > > > > > > Agree.
> >> >> > > > > > >
> >> >> > > > > > > >
> >> >> > > > > > > > >
> >> >> > > > > > > > > >
> >> >> > > > > > > > > > 6). And small remarks:
> >> >> > > > > > > > > > +jint vm_init1(JavaVM_Internal * java_vm,
> >> >> JavaVMInitArgs * vm_arguments);
> >> >> > > > > > > > > > +jint vm_init2(JNIEnv_Internal * jni_env);
> >> >> > > > > > > > > > Could you make names more meaningful, then 1,2,3...?
> >> >> > > > > > > > > Ok, will do that.
> >> >> > > > > > > > >
> >> >> > > > > > > > > >
> >> >> > > > > > > > > > class VM_thread {
> >> >> > > > > > > > > > ...
> >> >> > > > > > > > > > + JNIEnv_Internal * jni_env;
> >> >> > > > > > > > > > The jthread already has the jni_env pointer, you do
> >> >> not need to
> >> >> > > > > > > > > > duplicate it here.
> >> >> > > > > > > > > > forexample by using
> >> >> jthread_get_JNI_env(jthread_self());
> >> >> > > > > > > > >
> >> >> > > > > > > > > Yes I know. I don't see any problems here. Some times
> >> >> it is much more
> >> >> > > > > > > > > convenient to get JNIEnv from VM_thread structure (and
> >> >> faster) instead
> >> >> > > > > > > > > of doing jthread_get_JNI_env(jthread_self()). So I
> >> >> need strong
> >> >> > > > > > > > > arguments for removing it. Again it seems that should
> >> >> be addressed in
> >> >> > > > > > > > > design of multi VM. So lets forget about it for a
> >> >> while...
> >> >> > > > > > > >
> >> >> > > > > > > > I think that the data duplication would always serve as
> >> >> a potential
> >> >> > > > > > > > source of errors - while updating one copy of object,
> >> >> you may forget
> >> >> > > > > > > > to update the other, often resulting into a strange
> >> >> behavior of the
> >> >> > > > > > > > whole application. Let's see what are the specific
> >> >> performance
> >> >> > > > > > > > concerns that have to be addressed. To get VM_thread
> >> >> structure, you
> >> >> > > > > > > > would eventually go to the TLS, just like
> >> >> > > > > > > > jthread_get_JNI_env(jthread_self() would do.
> >> >> > > > > > > If there is already VM_thread structure for some reasons
> >> >> then there
> >> >> > > > > > > will be no extra access to TLS. It is definitely much
> >> more in
> >> >> > > > > > > jthread_get_JNI_env(jthread_self() than just one TLS
> >> >> access and one
> >> >> > > > > > > dereferncing. I don't think it is a really big problem
> >> >> now. Do you
> >> >> > > > > > > agree to look at this later. I guess multi VM
> >> >> implementation will
> >> >> > > > > > > alter it in any case.
> >> >> > > > > > >
> >> >> > > > > > > Thanks
> >> >> > > > > > > Evgueni
> >> >> > > > > > >
> >> >> > > > > > > >
> >> >> > > > > > > > Thanks,
> >> >> > > > > > > > Andrey.
> >> >> > > > > > > >
> >> >> > > > > > > > >
> >> >> > > > > > > > > Evgueni
> >> >> > > > > > > > > >
> >> >> > > > > > > > > > Thanks
> >> >> > > > > > > > > > Artem
> >> >> > > > > > > > > >
> >> >> > > > > > > > > > On 9/28/06, Evgueni Brevnov
> >> >> <ev...@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.
> >> >> > > > > > > > > > >
> >> >> > > > > > > > > > > Thanks
> >> >> > > > > > > > > > > Evgueni
> >> >> > > > > > > > > > >
> >> >> > > > > > > > > > > On 9/28/06, Geir Magnusson Jr. <ge...@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
> >> >> <we...@gmail.com> wrote:
> >> >> > > > > > > > > > > > >> On 9/26/06, Evgueni Brevnov
> >> >> <ev...@gmail.com> wrote:
> >> >> > > > > > > > > > > > >> >
> >> >> > > > > > > > > > > > >> > On 9/27/06, Andrey Chernyshev
> >> >> <a....@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
> >> >> > > > > > > > > > >
> >> >> > > > > > > > > > >
> >> >> > > > > > > > > >
> >> >> > > > > > > > > >
> >> >> ---------------------------------------------------------------------
> >> >> > > > > > > > > > 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
> >> >> > > > > > > > >
> >> >> > > > > > > > >
> >> >> > > > > > > >
> >> >> > > > > > > >
> >> >> > > > > > > > --
> >> >> > > > > > > > Andrey Chernyshev
> >> >> > > > > > > > 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
> >> >> > > > > >
> >> >> > > > > >
> >> >> > > > >
> >> >> > > > >
> >> >> > > > > --
> >> >> > > > > Andrey Chernyshev
> >> >> > > > > 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
> >> >> > > >
> >> >> > > >
> >> >> > >
> >> >> > >
> >> >> > > --
> >> >> > > Andrey Chernyshev
> >> >> > > 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
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > 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
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Nooooooo! LOL
I'm here waiting - This will unblock a whole bunch of things :)
Thanks for the effort
Evgueni Brevnov wrote:
> Geir,
>
> That's terrible. We have power outage....servers are down. I can't
> send the patches now.... will do it tomorrow
>
> Evgueni
> On 10/5/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>> woo hoo! here we go...
>>
>>
>> Andrey Chernyshev wrote:
>> > Hi Evgueni,
>> >
>> > On 10/4/06, Evgueni Brevnov <ev...@gmail.com> wrote:
>> >> Hi All,
>> >>
>> >> I have attached updated patch to the JIRA. It should resolve remain
>> >> concerns. Andrey, could you give a green light now?
>> >
>> > Thanks for updating the patch! I agree it it can be committed, at
>> > least signatures look good. 5 revisions seem like more than enough :).
>> > Anyways, I think the remaining issues can be resolved with additional
>> > patches. Thanks again for the good work and your patience.
>> >
>> > Thanks,
>> > Andrey.
>> >
>> >>
>> >> Thanks
>> >> Evgueni
>> >>
>> >> On 10/4/06, Evgueni Brevnov <ev...@gmail.com> wrote:
>> >> > Andrey,
>> >> >
>> >> > I see your points. I think both approaches have advantages and
>> >> > disadvantages. I think it is quite hard to say which approach is
>> >> > better until we play with one VM only. I still feel like introducing
>> >> > one more dependence is better than spreading code which deals with
>> >> > attachment among VM and TM. We really get stuck. OK, just because I
>> >> > want to move forward I will do required changes to remove
>> >> > vm_create_jthread from TM. I believe that will resolve all our
>> >> > disagreements and the patch will be applied soon.
>> >> >
>> >> >
>> >> > Thanks
>> >> > Evgueni.
>> >> >
>> >> > On 10/4/06, Andrey Chernyshev <a....@gmail.com> wrote:
>> >> > > On 10/3/06, Evgueni Brevnov <ev...@gmail.com> wrote:
>> >> > > > On 10/3/06, Andrey Chernyshev <a....@gmail.com> wrote:
>> >> > > > > On 10/2/06, Evgueni Brevnov <ev...@gmail.com> wrote:
>> >> > > > > > Andrey,
>> >> > > > > >
>> >> > > > > > Just to be clear.... I agree with you it is more
>> convenient if
>> >> > > > > > jthread_create takes JNIEnv instead of JavaVM. It
>> reflects that
>> >> > > > > > current thread has been attached already. Do you think it
>> >> makes sense
>> >> > > > > > to get rid of JNIEnv and use jthread_get_JNI_env in that
>> case?
>> >> > > > >
>> >> > > > > The jthread_* layer is designed like if it were a regular JNI
>> >> > > > > application which is meant to be called from the Java code,
>> hence
>> >> > > > > every function on that layer receives JNIenv. We can probably
>> >> get rid
>> >> > > > > of the JNEnv parameter for jthread_* functions, assuming that
>> >> TM can
>> >> > > > > always extract JNIenv for the current thread with
>> >> > > > > jthread_get_JNI_env().
>> >> > > > > My only concern would be the performance - once the JNIenv is
>> >> already
>> >> > > > > known for the native part of the kernel classes impl, it
>> must be
>> >> > > > > cheaper to pass JNIEnv to TM as an extra parameter rather than
>> >> extract
>> >> > > > > it from the TLS again.
>> >> > > > > Other than that, I see no strong advantages in keeping JNIEnv
>> >> parameter.
>> >> > > > >
>> >> > > > >
>> >> > > > > > Regarding jthread_attach. I still didn't get your point....
>> >> Clarify it
>> >> > > > > > please if you think jhread_attach should be modified.
>> >> > > > >
>> >> > > > > Sorry for being not clear: I think for jthread_attach, we have
>> >> two options:
>> >> > > > > 1) Make JNIEnv input parameter - it must be new JNIEnv that VM
>> >> > > > > pre-allocates for the new Java thread. jthread_attach
>> would just
>> >> > > > > associate it with the current thread.
>> >> > > > >
>> >> > > > > 2) Obtain JNIEnv via vm_attach() callback. In this case, if
>> >> > > > > vm_attach() callback implementation needs to know for which
>> >> JavaVM new
>> >> > > > > JNIenv has to be allocated, then we'll need to add JavaVM as
>> >> input
>> >> > > > > parameter for jthread_attach().
>> >> > > > > I think both options should be fine, (1) would probably
>> keep TM
>> >> > > > > interface a bit lighter, though (2) may look more closer to
>> >> the JNI
>> >> > > > > invocation API idea.
>> >> > > > > So I think adding JavaVM specifically for jthread_attach
>> may make
>> >> > > > > sense given the explanation you provided earlier.
>> >> > > > >
>> >> > > > > The concern I would have regarding the proposed jthread_attach
>> >> > > > > implementation is a call to vm_create_jthread() - this call
>> >> introduces
>> >> > > > > an extra dependency of TM on vmcore that I'd prefer to be
>> >> avoided. In
>> >> > > > > the original version, jthread_attach() was taking jthread
>> >> argument of
>> >> > > > > the already prepared j.l.Thread.
>> >> > > >
>> >> > > > I understand your concern. Unfortunately I don't see what we
>> can do
>> >> > > > here. Let me explain. In the beginning you have an unattached
>> >> native
>> >> > > > thread. To be able to call java code (which is required for
>> >> > > > constructing j.l.Thread instance) the thread should be attached
>> >> first.
>> >> > > > To be specific it should be attached to VM by calling vm_attach
>> >> which
>> >> > > > will return a valid JNIEnv It is valid to use JNI from that
>> moment.
>> >> > > > Obtained JNIEnv can be used to execute java code and create
>> >> j.l.Thread
>> >> > > > instance. Since we do vm_attach in jthread_attach we need to do
>> >> > > > vm_create_jthread inside jthread_atach as well.
>> >> > > > Of course it can be an alternative to do vm_attach and
>> >> > > > vm_create_jthread outside of TM right before jthread_attach.
>> >> Sure it
>> >> > > > will reduce one dependence between VM and TM. But it seems like
>> >> > > > artificial action for me just because of dependency....
>> >> > >
>> >> > > Why do you think it is artificial? I would rather prefer not to
>> throw
>> >> > > vm_attach event from the jthread_attach() call at all than to add
>> >> > > extra dependency. The idea of jthread layer is a Java face to
>> >> > > hythread, it is meant to know either a little or nothing about the
>> >> > > rest of VM. It may be logical to throw vm_attach call from the
>> newly
>> >> > > created thread, because there is no other way to let know VM
>> the new
>> >> > > thread is created. VM attach is a different case - VM already
>> knows
>> >> > > about new Java thread at the time of the AttachCurrentThread call.
>> >> > >
>> >> > > >
>> >> > > > > Do you think it makes sense to replace a single jthread
>> >> parameter with
>> >> > > > > a variety of stuff (like thread group, name)? It seems the
>> only
>> >> > > > > purpose of at these args is to be passed back to VM for
>> >> > > > > vm_jthread_create(). I would suggest to change this and try
>> doing
>> >> > > > > either of:
>> >> > > > > 1) Make signature of jthread_attach with 3 args, JavaVM,
>> >> jthread and the daemon.
>> >> > > > Why do you want to pass daemon to TM but thread's name and
>> >> group. Just
>> >> > > > because current TM doesn't need such information? What if it is
>> >> > > > required to get thread name later? Say by introducing
>> >> > >
>> >> > > I imagine you need a daemon attribute since the TM is still
>> managing
>> >> > > the thread daemonality. TM is not managing thread name and group -
>> >> > > they are all kept on the Java level, hence passing them may be
>> >> > > excessive.
>> >> > >
>> >> > > > jthread_get_name... What will you do in that case? Let me
>> guess you
>> >> > > > will call j.l.Thread.getName. Right. Ok! In that case I see no
>> >> > > > problems to call j.l.Thread.isDaemon. Do you agree? So it
>> doesn't
>> >> > >
>> >> > > As I suggested earlier, the best way to handle daemonality would
>> >> > > probably be in pure Java - in j.l.Thread (or
>> j.l.VMThreadManager) or
>> >> > > whatever. You already lifted it up to the jthread level, but
>> what if
>> >> > > we can go a little bit higher...
>> >> > >
>> >> > > > seems to be a good design to pass only part of the
>> information to
>> >> > > > jthread_atach. Lets look at the signature of
>> >> AttachCurrentThread. It
>> >> > > > takes exactly these three parameters (daemon, name, group)
>> >> passed as a
>> >> > > > structure. I was thinking about having exactly the same
>> >> structure as
>> >> > > > third parameter of jthread_attach but it occured to be more
>> >> convinient
>> >> > > > to pass them seperatly. Although I don't see strong reasons
>> against
>> >> > > > having a structure a third parameter.
>> >> > >
>> >> > > I see. Acually, I would love to keep the jthread_attach func-ty at
>> >> the
>> >> > > minimum level which will be needed to handle the only data that TM
>> >> > > should be aware of. We need a formal boundary between jthread
>> layer
>> >> > > and vmcore (otherwise jthread won't have a much of sense, one may
>> >> > > consider it just as a convenience set of functions in vmcore which
>> >> are
>> >> > > doing something with threading).
>> >> > >
>> >> > > >
>> >> > > > > 2) Move the implementation of vm_create_jtrhead() to
>> >> > > > > thread_java_basic.c - could it be written in pure JNI without
>> >> using
>> >> > > > > internal VM API like class_alloc_new_object()?
>> >> > > >
>> >> > > > Yes, this can be done but it doesn't fix the problem. You still
>> >> need
>> >> > > > to know about internal constructor of j.l.Thread
>> >> > >
>> >> > > That's bad. Given what you said, now it seems that the most
>> >> preferable
>> >> > > sequence for AttachCurrentThread impl still would be like:
>> >> > > JNIEnv = vm_attach();
>> >> > > jthread = create_jthread(JNIenv)
>> >> > > jthread_attach(JNIEnv, jthread) // stores JNIEnv and Hythread into
>> >> > > TLS, doesn't call vm_attach any longer.
>> >> > > - this is almost what we had from the beginning...
>> >> > >
>> >> > > Thanks,
>> >> > > Andrey.
>> >> > >
>> >> > > >
>> >> > > >
>> >> > > > Thanks
>> >> > > > Evgueni
>> >> > > > >
>> >> > > > >
>> >> > > > > Thanks,
>> >> > > > > Andrey.
>> >> > > > >
>> >> > > > > >
>> >> > > > > > Thank you
>> >> > > > > > Evgueni
>> >> > > > > >
>> >> > > > > > On 10/2/06, Evgueni Brevnov <ev...@gmail.com>
>> wrote:
>> >> > > > > > > On 9/29/06, Andrey Chernyshev <a....@gmail.com>
>> >> wrote:
>> >> > > > > > > > On 9/29/06, Evgueni Brevnov <ev...@gmail.com>
>> >> wrote:
>> >> > > > > > > > > Artem,
>> >> > > > > > > > >
>> >> > > > > > > > > Thank you for your feedback.... find my inlined.....
>> >> > > > > > > > >
>> >> > > > > > > > > On 9/29/06, Artem Aliev <ar...@gmail.com> wrote:
>> >> > > > > > > > > > Evgueni,
>> >> > > > > > > > > >
>> >> > > > > > > > > > I got most of your changes, but still disagree
>> with all
>> >> > > > > > > > > > hythread/jthread interface changes. Could leave
>> >> interface unchanged.
>> >> > > > > > > > > > See following possible solutions, that could solve
>> >> the same problems
>> >> > > > > > > > > > without interface changes.
>> >> > > > > > > > > >
>> >> > > > > > > > > >
>> >> > > > > > > > > > 1) daemon attribute is a java specific. (Andrey
>> >> mentioned this already).
>> >> > > > > > > > > > Could you please move it back. to the jthread
>> >> layer. It is better
>> >> > > > > > > > > > to rename
>> >> > > > > > > > > > hythread_wait_for_all_nondaemon_threads() to
>> >> > > > > > > > > > jthread_wait_for_all_nondaemon_threads().
>> >> > > > > > > > > Ok, I see no problems to move "daemon" to java layer.
>> >> In that case:
>> >> > > > > > > > > 1) I will move
>> >> hythread_wait_for_all_nondaemon_threads() from
>> >> > > > > > > > > thread_init.c to one which implements java layer.
>> >> > > > > > > > > 2) I will move daemon field from HyThread structure.
>> >> > > > > > > > >
>> >> > > > > > > > > Agree?
>> >> > > > > > > >
>> >> > > > > > > > Sounds good to me.
>> >> > > > > > >
>> >> > > > > > > OK, will do that.
>> >> > > > > > >
>> >> > > > > > > >
>> >> > > > > > > >
>> >> > > > > > > > >
>> >> > > > > > > > > >
>> >> > > > > > > > > > 2) JavaVM could be retrieved from JNIEnv by
>> >> jni_get_java_vm(). So
>> >> > > > > > > > > > let the jthread_create() and others to use JNIEnv
>> >> (that is passed from
>> >> > > > > > > > > > java native method).
>> >> > > > > > > > > > The vm_attach could get old JNI env and create new
>> >> one for the new thread.
>> >> > > > > > > > > > The first JNIEnv is created in CreateVM call and
>> >> could be passed to
>> >> > > > > > > > > > the first thread at startup.
>> >> > > > > > > > > No, no, no. I completely disagree with that!!! Why do
>> >> you like JNIEnv
>> >> > > > > > > > > but JavaVM. Why do you think that passing JavaVM
>> >> instead of JNIEnv
>> >> > > > > > > > > makes TM less modular? I don't see any difference
>> >> here.... It seems
>> >> > > > > > > > > for me like a big big hack to grab JNIEnv from another
>> >> thread and pass
>> >> > > > > > > > > it to jthread_attach to perform operations in the
>> >> current thread.
>> >> > > > > > > >
>> >> > > > > > > > TM needs to know JNIEnv, mainly for managing the
>> >> references to
>> >> > > > > > > > objects, throwing exceptions and calling run() method of
>> >> a new thread.
>> >> > > > > > > > JNI spec proposes that JNIEnv is valid within the given
>> >> thread, this
>> >> > > > > > > > is why TM holds the JNIEnv pointer at the moment. This
>> >> is why TM likes
>> >> > > > > > > > the JNIEnv.
>> >> > > > > > > >
>> >> > > > > > > > Having the JNIEnv, one is able to get JavaVM but not
>> >> vise versa. This
>> >> > > > > > > > is why TM doesn't like the JavaVM :)
>> >> > > > > > > I see your point. Only one note this is true for already
>> >> attached threads...
>> >> > > > > > >
>> >> > > > > > > >
>> >> > > > > > > > I agree with you that there is a design flaw that the
>> >> JNIEnv is copied
>> >> > > > > > > > from the parent thread to a child thread during thread
>> >> creation. I
>> >> > > > > > > > think it could be resolved via vm_attach() hook - with
>> >> this event, VM
>> >> > > > > > > > might tell the TM what the JNIEnv pointer for new thread
>> >> should be. I
>> >> > > > > > > > think you did that by extending the vm_attach() call
>> >> with the JNIEnv**
>> >> > > > > > > > argument.
>> >> > > > > > > >
>> >> > > > > > > > What is not completely clear is, why do you have to pass
>> >> the JavaVM
>> >> > > > > > > > forth and back, once from VM to TM, and then back from
>> >> TM to VM again?
>> >> > > > > > > >
>> >> > > > > > > > If you need to know in jthread_attach, which particular
>> >> VM vm_attach()
>> >> > > > > > > > event is coming from, you could have vm_attach like
>> >> > > > > > > > vm_attach(JNIEnv* currentThreadEnv, JNIEnv**
>> >> newThreadEnv).
>> >> > > > > > > I'm a little bit confused.....Current thread hasn't been
>> >> attached yet.
>> >> > > > > > > So there is no JNIEnv for it yet. How it can be passed as
>> >> the first
>> >> > > > > > > parameter to vm_attach()?
>> >> > > > > > >
>> >> > > > > > > > Then you will be always able to get the JavaVM from the
>> >> JNIEnv.
>> >> > > > > > > > The only difference is that you are currently doing
>> >> JNIEnv->JavaVM
>> >> > > > > > > > conversion in the VMThreadManager, but why can't you
>> >> just do this in
>> >> > > > > > > > vm_attach() without changing the interface of the TM?
>> >> > > > > > > > So far JavaVM really looks like an extra knowledge that
>> >> TM doesn't
>> >> > > > > > > > have to be aware of.
>> >> > > > > > > >
>> >> > > > > > > > > Moreover there is no JNIEnv when main thread attaches
>> >> to VM. So we
>> >> > > > > > > > > should either keep it as is or change original design
>> >> of TM and attach
>> >> > > > > > > > > thread to VM before attaching it to TM. In that case
>> >> we will have
>> >> > > > > > > > > valid JNIEnv which can be passed to jthread_atatch. We
>> >> need to think
>> >> > > > > > > > > over it twice before changing something....
>> >> > > > > > > >
>> >> > > > > > > > Right. For jthread_attach, JNIenv needs to be changed
>> >> from being input
>> >> > > > > > > > parameter to being the output parameter. The way how
>> >> JNIenv is
>> >> > > > > > > > obtained by TM should be vm_attach() event.
>> >> > > > > > > OK, JNIEnv is output parameter. And it obtained by
>> >> vm_attach(). This
>> >> > > > > > > is exactly like I do in the patch. What I don't understand
>> >> is how
>> >> > > > > > > jthread_attach knows to which VM the thread should be
>> >> attached? Do you
>> >> > > > > > > suggest calling vm_attach first to create JNIEnv it pass
>> >> it to
>> >> > > > > > > jthread_attach?
>> >> > > > > > >
>> >> > > > > > > >
>> >> > > > > > > > >
>> >> > > > > > > > >
>> >> > > > > > > > >
>> >> > > > > > > > > >
>> >> > > > > > > > > >
>> >> > > > > > > > > > 4) Original classlib hythread do not use
>> >> hythread_library_t in arguments,
>> >> > > > > > > > > > It uses following code:
>> >> > > > > > > > > >
>> >> > > > > > > > > > hythread_library_t lib = GLOBAL_DATA
>> >> (default_library);
>> >> > > > > > > > > > or
>> >> > > > > > > > > > hythread_library_t library = thread->library;
>> >> > > > > > > > > >
>> >> > > > > > > > > > So could you please use the same mechanism and
>> >> remove hythread_*_ex >functions.
>> >> > > > > > > > > Let's see if classlib's hythread needs changing first.
>> >> It seems for me
>> >> > > > > > > > > such code prevents us from having multi VM.
>> >> > > > > > > > >
>> >> > > > > > > > > >
>> >> > > > > > > > > > 5. You introduce more then one jni env, but still
>> >> use global variable for it.
>> >> > > > > > > > > > So all changes like following:
>> >> > > > > > > > > > - JNIEnv *jenv = (JNIEnv*)jni_native_intf;
>> >> > > > > > > > > > + JNIEnv *jenv = jni_native_intf;
>> >> > > > > > > > > >
>> >> > > > > > > > > > should be like:
>> >> > > > > > > > > > - JNIEnv *jenv = (JNIEnv*)jni_native_intf;
>> >> > > > > > > > > > + JNIEnv *jenv = get_jni_env(jthread_self());
>> >> > > > > > > > >
>> >> > > > > > > > > Ok, I see. I agree that global jni_native_intf should
>> >> not be used.
>> >> > > > > > > > > There was simple reason why I altered such lines.
>> >> Because I changed
>> >> > > > > > > > > the type of jni_native_intf and no casting operator
>> >> is needed now. To
>> >> > > > > > > > > be honest I think get_jni_env(jthread_self()) can be
>> >> good as temporary
>> >> > > > > > > > > solution only. Lets wait for design of multi VM and
>> >> fix it according
>> >> > > > > > > > > to it.
>> >> > > > > > > >
>> >> > > > > > > > While we are in JNI code, we always have the JNIenv (at
>> >> least
>> >> > > > > > > > initially it comes from Java code). If we consider VM
>> >> code as if it
>> >> > > > > > > > was a JNI application, then it seems like we should be
>> >> just passing
>> >> > > > > > > > JNIEnv as a parameter to all functions in VM. Or, we can
>> >> be taking it
>> >> > > > > > > > from TLS (via jthread_self()), depending on which way is
>> >> faster...
>> >> > > > > > > Agree.
>> >> > > > > > >
>> >> > > > > > > >
>> >> > > > > > > > >
>> >> > > > > > > > > >
>> >> > > > > > > > > > 6). And small remarks:
>> >> > > > > > > > > > +jint vm_init1(JavaVM_Internal * java_vm,
>> >> JavaVMInitArgs * vm_arguments);
>> >> > > > > > > > > > +jint vm_init2(JNIEnv_Internal * jni_env);
>> >> > > > > > > > > > Could you make names more meaningful, then 1,2,3...?
>> >> > > > > > > > > Ok, will do that.
>> >> > > > > > > > >
>> >> > > > > > > > > >
>> >> > > > > > > > > > class VM_thread {
>> >> > > > > > > > > > ...
>> >> > > > > > > > > > + JNIEnv_Internal * jni_env;
>> >> > > > > > > > > > The jthread already has the jni_env pointer, you do
>> >> not need to
>> >> > > > > > > > > > duplicate it here.
>> >> > > > > > > > > > forexample by using
>> >> jthread_get_JNI_env(jthread_self());
>> >> > > > > > > > >
>> >> > > > > > > > > Yes I know. I don't see any problems here. Some times
>> >> it is much more
>> >> > > > > > > > > convenient to get JNIEnv from VM_thread structure (and
>> >> faster) instead
>> >> > > > > > > > > of doing jthread_get_JNI_env(jthread_self()). So I
>> >> need strong
>> >> > > > > > > > > arguments for removing it. Again it seems that should
>> >> be addressed in
>> >> > > > > > > > > design of multi VM. So lets forget about it for a
>> >> while...
>> >> > > > > > > >
>> >> > > > > > > > I think that the data duplication would always serve as
>> >> a potential
>> >> > > > > > > > source of errors - while updating one copy of object,
>> >> you may forget
>> >> > > > > > > > to update the other, often resulting into a strange
>> >> behavior of the
>> >> > > > > > > > whole application. Let's see what are the specific
>> >> performance
>> >> > > > > > > > concerns that have to be addressed. To get VM_thread
>> >> structure, you
>> >> > > > > > > > would eventually go to the TLS, just like
>> >> > > > > > > > jthread_get_JNI_env(jthread_self() would do.
>> >> > > > > > > If there is already VM_thread structure for some reasons
>> >> then there
>> >> > > > > > > will be no extra access to TLS. It is definitely much
>> more in
>> >> > > > > > > jthread_get_JNI_env(jthread_self() than just one TLS
>> >> access and one
>> >> > > > > > > dereferncing. I don't think it is a really big problem
>> >> now. Do you
>> >> > > > > > > agree to look at this later. I guess multi VM
>> >> implementation will
>> >> > > > > > > alter it in any case.
>> >> > > > > > >
>> >> > > > > > > Thanks
>> >> > > > > > > Evgueni
>> >> > > > > > >
>> >> > > > > > > >
>> >> > > > > > > > Thanks,
>> >> > > > > > > > Andrey.
>> >> > > > > > > >
>> >> > > > > > > > >
>> >> > > > > > > > > Evgueni
>> >> > > > > > > > > >
>> >> > > > > > > > > > Thanks
>> >> > > > > > > > > > Artem
>> >> > > > > > > > > >
>> >> > > > > > > > > > On 9/28/06, Evgueni Brevnov
>> >> <ev...@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.
>> >> > > > > > > > > > >
>> >> > > > > > > > > > > Thanks
>> >> > > > > > > > > > > Evgueni
>> >> > > > > > > > > > >
>> >> > > > > > > > > > > On 9/28/06, Geir Magnusson Jr. <ge...@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
>> >> <we...@gmail.com> wrote:
>> >> > > > > > > > > > > > >> On 9/26/06, Evgueni Brevnov
>> >> <ev...@gmail.com> wrote:
>> >> > > > > > > > > > > > >> >
>> >> > > > > > > > > > > > >> > On 9/27/06, Andrey Chernyshev
>> >> <a....@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
>> >> > > > > > > > > > >
>> >> > > > > > > > > > >
>> >> > > > > > > > > >
>> >> > > > > > > > > >
>> >> ---------------------------------------------------------------------
>> >> > > > > > > > > > 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
>> >> > > > > > > > >
>> >> > > > > > > > >
>> >> > > > > > > >
>> >> > > > > > > >
>> >> > > > > > > > --
>> >> > > > > > > > Andrey Chernyshev
>> >> > > > > > > > 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
>> >> > > > > >
>> >> > > > > >
>> >> > > > >
>> >> > > > >
>> >> > > > > --
>> >> > > > > Andrey Chernyshev
>> >> > > > > 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
>> >> > > >
>> >> > > >
>> >> > >
>> >> > >
>> >> > > --
>> >> > > Andrey Chernyshev
>> >> > > 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
>>
>>
>
> ---------------------------------------------------------------------
> 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
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
Posted by Evgueni Brevnov <ev...@gmail.com>.
Geir,
That's terrible. We have power outage....servers are down. I can't
send the patches now.... will do it tomorrow
Evgueni
On 10/5/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> woo hoo! here we go...
>
>
> Andrey Chernyshev wrote:
> > Hi Evgueni,
> >
> > On 10/4/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> >> Hi All,
> >>
> >> I have attached updated patch to the JIRA. It should resolve remain
> >> concerns. Andrey, could you give a green light now?
> >
> > Thanks for updating the patch! I agree it it can be committed, at
> > least signatures look good. 5 revisions seem like more than enough :).
> > Anyways, I think the remaining issues can be resolved with additional
> > patches. Thanks again for the good work and your patience.
> >
> > Thanks,
> > Andrey.
> >
> >>
> >> Thanks
> >> Evgueni
> >>
> >> On 10/4/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> >> > Andrey,
> >> >
> >> > I see your points. I think both approaches have advantages and
> >> > disadvantages. I think it is quite hard to say which approach is
> >> > better until we play with one VM only. I still feel like introducing
> >> > one more dependence is better than spreading code which deals with
> >> > attachment among VM and TM. We really get stuck. OK, just because I
> >> > want to move forward I will do required changes to remove
> >> > vm_create_jthread from TM. I believe that will resolve all our
> >> > disagreements and the patch will be applied soon.
> >> >
> >> >
> >> > Thanks
> >> > Evgueni.
> >> >
> >> > On 10/4/06, Andrey Chernyshev <a....@gmail.com> wrote:
> >> > > On 10/3/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> >> > > > On 10/3/06, Andrey Chernyshev <a....@gmail.com> wrote:
> >> > > > > On 10/2/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> >> > > > > > Andrey,
> >> > > > > >
> >> > > > > > Just to be clear.... I agree with you it is more convenient if
> >> > > > > > jthread_create takes JNIEnv instead of JavaVM. It reflects that
> >> > > > > > current thread has been attached already. Do you think it
> >> makes sense
> >> > > > > > to get rid of JNIEnv and use jthread_get_JNI_env in that case?
> >> > > > >
> >> > > > > The jthread_* layer is designed like if it were a regular JNI
> >> > > > > application which is meant to be called from the Java code, hence
> >> > > > > every function on that layer receives JNIenv. We can probably
> >> get rid
> >> > > > > of the JNEnv parameter for jthread_* functions, assuming that
> >> TM can
> >> > > > > always extract JNIenv for the current thread with
> >> > > > > jthread_get_JNI_env().
> >> > > > > My only concern would be the performance - once the JNIenv is
> >> already
> >> > > > > known for the native part of the kernel classes impl, it must be
> >> > > > > cheaper to pass JNIEnv to TM as an extra parameter rather than
> >> extract
> >> > > > > it from the TLS again.
> >> > > > > Other than that, I see no strong advantages in keeping JNIEnv
> >> parameter.
> >> > > > >
> >> > > > >
> >> > > > > > Regarding jthread_attach. I still didn't get your point....
> >> Clarify it
> >> > > > > > please if you think jhread_attach should be modified.
> >> > > > >
> >> > > > > Sorry for being not clear: I think for jthread_attach, we have
> >> two options:
> >> > > > > 1) Make JNIEnv input parameter - it must be new JNIEnv that VM
> >> > > > > pre-allocates for the new Java thread. jthread_attach would just
> >> > > > > associate it with the current thread.
> >> > > > >
> >> > > > > 2) Obtain JNIEnv via vm_attach() callback. In this case, if
> >> > > > > vm_attach() callback implementation needs to know for which
> >> JavaVM new
> >> > > > > JNIenv has to be allocated, then we'll need to add JavaVM as
> >> input
> >> > > > > parameter for jthread_attach().
> >> > > > > I think both options should be fine, (1) would probably keep TM
> >> > > > > interface a bit lighter, though (2) may look more closer to
> >> the JNI
> >> > > > > invocation API idea.
> >> > > > > So I think adding JavaVM specifically for jthread_attach may make
> >> > > > > sense given the explanation you provided earlier.
> >> > > > >
> >> > > > > The concern I would have regarding the proposed jthread_attach
> >> > > > > implementation is a call to vm_create_jthread() - this call
> >> introduces
> >> > > > > an extra dependency of TM on vmcore that I'd prefer to be
> >> avoided. In
> >> > > > > the original version, jthread_attach() was taking jthread
> >> argument of
> >> > > > > the already prepared j.l.Thread.
> >> > > >
> >> > > > I understand your concern. Unfortunately I don't see what we can do
> >> > > > here. Let me explain. In the beginning you have an unattached
> >> native
> >> > > > thread. To be able to call java code (which is required for
> >> > > > constructing j.l.Thread instance) the thread should be attached
> >> first.
> >> > > > To be specific it should be attached to VM by calling vm_attach
> >> which
> >> > > > will return a valid JNIEnv It is valid to use JNI from that moment.
> >> > > > Obtained JNIEnv can be used to execute java code and create
> >> j.l.Thread
> >> > > > instance. Since we do vm_attach in jthread_attach we need to do
> >> > > > vm_create_jthread inside jthread_atach as well.
> >> > > > Of course it can be an alternative to do vm_attach and
> >> > > > vm_create_jthread outside of TM right before jthread_attach.
> >> Sure it
> >> > > > will reduce one dependence between VM and TM. But it seems like
> >> > > > artificial action for me just because of dependency....
> >> > >
> >> > > Why do you think it is artificial? I would rather prefer not to throw
> >> > > vm_attach event from the jthread_attach() call at all than to add
> >> > > extra dependency. The idea of jthread layer is a Java face to
> >> > > hythread, it is meant to know either a little or nothing about the
> >> > > rest of VM. It may be logical to throw vm_attach call from the newly
> >> > > created thread, because there is no other way to let know VM the new
> >> > > thread is created. VM attach is a different case - VM already knows
> >> > > about new Java thread at the time of the AttachCurrentThread call.
> >> > >
> >> > > >
> >> > > > > Do you think it makes sense to replace a single jthread
> >> parameter with
> >> > > > > a variety of stuff (like thread group, name)? It seems the only
> >> > > > > purpose of at these args is to be passed back to VM for
> >> > > > > vm_jthread_create(). I would suggest to change this and try doing
> >> > > > > either of:
> >> > > > > 1) Make signature of jthread_attach with 3 args, JavaVM,
> >> jthread and the daemon.
> >> > > > Why do you want to pass daemon to TM but thread's name and
> >> group. Just
> >> > > > because current TM doesn't need such information? What if it is
> >> > > > required to get thread name later? Say by introducing
> >> > >
> >> > > I imagine you need a daemon attribute since the TM is still managing
> >> > > the thread daemonality. TM is not managing thread name and group -
> >> > > they are all kept on the Java level, hence passing them may be
> >> > > excessive.
> >> > >
> >> > > > jthread_get_name... What will you do in that case? Let me guess you
> >> > > > will call j.l.Thread.getName. Right. Ok! In that case I see no
> >> > > > problems to call j.l.Thread.isDaemon. Do you agree? So it doesn't
> >> > >
> >> > > As I suggested earlier, the best way to handle daemonality would
> >> > > probably be in pure Java - in j.l.Thread (or j.l.VMThreadManager) or
> >> > > whatever. You already lifted it up to the jthread level, but what if
> >> > > we can go a little bit higher...
> >> > >
> >> > > > seems to be a good design to pass only part of the information to
> >> > > > jthread_atach. Lets look at the signature of
> >> AttachCurrentThread. It
> >> > > > takes exactly these three parameters (daemon, name, group)
> >> passed as a
> >> > > > structure. I was thinking about having exactly the same
> >> structure as
> >> > > > third parameter of jthread_attach but it occured to be more
> >> convinient
> >> > > > to pass them seperatly. Although I don't see strong reasons against
> >> > > > having a structure a third parameter.
> >> > >
> >> > > I see. Acually, I would love to keep the jthread_attach func-ty at
> >> the
> >> > > minimum level which will be needed to handle the only data that TM
> >> > > should be aware of. We need a formal boundary between jthread layer
> >> > > and vmcore (otherwise jthread won't have a much of sense, one may
> >> > > consider it just as a convenience set of functions in vmcore which
> >> are
> >> > > doing something with threading).
> >> > >
> >> > > >
> >> > > > > 2) Move the implementation of vm_create_jtrhead() to
> >> > > > > thread_java_basic.c - could it be written in pure JNI without
> >> using
> >> > > > > internal VM API like class_alloc_new_object()?
> >> > > >
> >> > > > Yes, this can be done but it doesn't fix the problem. You still
> >> need
> >> > > > to know about internal constructor of j.l.Thread
> >> > >
> >> > > That's bad. Given what you said, now it seems that the most
> >> preferable
> >> > > sequence for AttachCurrentThread impl still would be like:
> >> > > JNIEnv = vm_attach();
> >> > > jthread = create_jthread(JNIenv)
> >> > > jthread_attach(JNIEnv, jthread) // stores JNIEnv and Hythread into
> >> > > TLS, doesn't call vm_attach any longer.
> >> > > - this is almost what we had from the beginning...
> >> > >
> >> > > Thanks,
> >> > > Andrey.
> >> > >
> >> > > >
> >> > > >
> >> > > > Thanks
> >> > > > Evgueni
> >> > > > >
> >> > > > >
> >> > > > > Thanks,
> >> > > > > Andrey.
> >> > > > >
> >> > > > > >
> >> > > > > > Thank you
> >> > > > > > Evgueni
> >> > > > > >
> >> > > > > > On 10/2/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> >> > > > > > > On 9/29/06, Andrey Chernyshev <a....@gmail.com>
> >> wrote:
> >> > > > > > > > On 9/29/06, Evgueni Brevnov <ev...@gmail.com>
> >> wrote:
> >> > > > > > > > > Artem,
> >> > > > > > > > >
> >> > > > > > > > > Thank you for your feedback.... find my inlined.....
> >> > > > > > > > >
> >> > > > > > > > > On 9/29/06, Artem Aliev <ar...@gmail.com> wrote:
> >> > > > > > > > > > Evgueni,
> >> > > > > > > > > >
> >> > > > > > > > > > I got most of your changes, but still disagree with all
> >> > > > > > > > > > hythread/jthread interface changes. Could leave
> >> interface unchanged.
> >> > > > > > > > > > See following possible solutions, that could solve
> >> the same problems
> >> > > > > > > > > > without interface changes.
> >> > > > > > > > > >
> >> > > > > > > > > >
> >> > > > > > > > > > 1) daemon attribute is a java specific. (Andrey
> >> mentioned this already).
> >> > > > > > > > > > Could you please move it back. to the jthread
> >> layer. It is better
> >> > > > > > > > > > to rename
> >> > > > > > > > > > hythread_wait_for_all_nondaemon_threads() to
> >> > > > > > > > > > jthread_wait_for_all_nondaemon_threads().
> >> > > > > > > > > Ok, I see no problems to move "daemon" to java layer.
> >> In that case:
> >> > > > > > > > > 1) I will move
> >> hythread_wait_for_all_nondaemon_threads() from
> >> > > > > > > > > thread_init.c to one which implements java layer.
> >> > > > > > > > > 2) I will move daemon field from HyThread structure.
> >> > > > > > > > >
> >> > > > > > > > > Agree?
> >> > > > > > > >
> >> > > > > > > > Sounds good to me.
> >> > > > > > >
> >> > > > > > > OK, will do that.
> >> > > > > > >
> >> > > > > > > >
> >> > > > > > > >
> >> > > > > > > > >
> >> > > > > > > > > >
> >> > > > > > > > > > 2) JavaVM could be retrieved from JNIEnv by
> >> jni_get_java_vm(). So
> >> > > > > > > > > > let the jthread_create() and others to use JNIEnv
> >> (that is passed from
> >> > > > > > > > > > java native method).
> >> > > > > > > > > > The vm_attach could get old JNI env and create new
> >> one for the new thread.
> >> > > > > > > > > > The first JNIEnv is created in CreateVM call and
> >> could be passed to
> >> > > > > > > > > > the first thread at startup.
> >> > > > > > > > > No, no, no. I completely disagree with that!!! Why do
> >> you like JNIEnv
> >> > > > > > > > > but JavaVM. Why do you think that passing JavaVM
> >> instead of JNIEnv
> >> > > > > > > > > makes TM less modular? I don't see any difference
> >> here.... It seems
> >> > > > > > > > > for me like a big big hack to grab JNIEnv from another
> >> thread and pass
> >> > > > > > > > > it to jthread_attach to perform operations in the
> >> current thread.
> >> > > > > > > >
> >> > > > > > > > TM needs to know JNIEnv, mainly for managing the
> >> references to
> >> > > > > > > > objects, throwing exceptions and calling run() method of
> >> a new thread.
> >> > > > > > > > JNI spec proposes that JNIEnv is valid within the given
> >> thread, this
> >> > > > > > > > is why TM holds the JNIEnv pointer at the moment. This
> >> is why TM likes
> >> > > > > > > > the JNIEnv.
> >> > > > > > > >
> >> > > > > > > > Having the JNIEnv, one is able to get JavaVM but not
> >> vise versa. This
> >> > > > > > > > is why TM doesn't like the JavaVM :)
> >> > > > > > > I see your point. Only one note this is true for already
> >> attached threads...
> >> > > > > > >
> >> > > > > > > >
> >> > > > > > > > I agree with you that there is a design flaw that the
> >> JNIEnv is copied
> >> > > > > > > > from the parent thread to a child thread during thread
> >> creation. I
> >> > > > > > > > think it could be resolved via vm_attach() hook - with
> >> this event, VM
> >> > > > > > > > might tell the TM what the JNIEnv pointer for new thread
> >> should be. I
> >> > > > > > > > think you did that by extending the vm_attach() call
> >> with the JNIEnv**
> >> > > > > > > > argument.
> >> > > > > > > >
> >> > > > > > > > What is not completely clear is, why do you have to pass
> >> the JavaVM
> >> > > > > > > > forth and back, once from VM to TM, and then back from
> >> TM to VM again?
> >> > > > > > > >
> >> > > > > > > > If you need to know in jthread_attach, which particular
> >> VM vm_attach()
> >> > > > > > > > event is coming from, you could have vm_attach like
> >> > > > > > > > vm_attach(JNIEnv* currentThreadEnv, JNIEnv**
> >> newThreadEnv).
> >> > > > > > > I'm a little bit confused.....Current thread hasn't been
> >> attached yet.
> >> > > > > > > So there is no JNIEnv for it yet. How it can be passed as
> >> the first
> >> > > > > > > parameter to vm_attach()?
> >> > > > > > >
> >> > > > > > > > Then you will be always able to get the JavaVM from the
> >> JNIEnv.
> >> > > > > > > > The only difference is that you are currently doing
> >> JNIEnv->JavaVM
> >> > > > > > > > conversion in the VMThreadManager, but why can't you
> >> just do this in
> >> > > > > > > > vm_attach() without changing the interface of the TM?
> >> > > > > > > > So far JavaVM really looks like an extra knowledge that
> >> TM doesn't
> >> > > > > > > > have to be aware of.
> >> > > > > > > >
> >> > > > > > > > > Moreover there is no JNIEnv when main thread attaches
> >> to VM. So we
> >> > > > > > > > > should either keep it as is or change original design
> >> of TM and attach
> >> > > > > > > > > thread to VM before attaching it to TM. In that case
> >> we will have
> >> > > > > > > > > valid JNIEnv which can be passed to jthread_atatch. We
> >> need to think
> >> > > > > > > > > over it twice before changing something....
> >> > > > > > > >
> >> > > > > > > > Right. For jthread_attach, JNIenv needs to be changed
> >> from being input
> >> > > > > > > > parameter to being the output parameter. The way how
> >> JNIenv is
> >> > > > > > > > obtained by TM should be vm_attach() event.
> >> > > > > > > OK, JNIEnv is output parameter. And it obtained by
> >> vm_attach(). This
> >> > > > > > > is exactly like I do in the patch. What I don't understand
> >> is how
> >> > > > > > > jthread_attach knows to which VM the thread should be
> >> attached? Do you
> >> > > > > > > suggest calling vm_attach first to create JNIEnv it pass
> >> it to
> >> > > > > > > jthread_attach?
> >> > > > > > >
> >> > > > > > > >
> >> > > > > > > > >
> >> > > > > > > > >
> >> > > > > > > > >
> >> > > > > > > > > >
> >> > > > > > > > > >
> >> > > > > > > > > > 4) Original classlib hythread do not use
> >> hythread_library_t in arguments,
> >> > > > > > > > > > It uses following code:
> >> > > > > > > > > >
> >> > > > > > > > > > hythread_library_t lib = GLOBAL_DATA
> >> (default_library);
> >> > > > > > > > > > or
> >> > > > > > > > > > hythread_library_t library = thread->library;
> >> > > > > > > > > >
> >> > > > > > > > > > So could you please use the same mechanism and
> >> remove hythread_*_ex >functions.
> >> > > > > > > > > Let's see if classlib's hythread needs changing first.
> >> It seems for me
> >> > > > > > > > > such code prevents us from having multi VM.
> >> > > > > > > > >
> >> > > > > > > > > >
> >> > > > > > > > > > 5. You introduce more then one jni env, but still
> >> use global variable for it.
> >> > > > > > > > > > So all changes like following:
> >> > > > > > > > > > - JNIEnv *jenv = (JNIEnv*)jni_native_intf;
> >> > > > > > > > > > + JNIEnv *jenv = jni_native_intf;
> >> > > > > > > > > >
> >> > > > > > > > > > should be like:
> >> > > > > > > > > > - JNIEnv *jenv = (JNIEnv*)jni_native_intf;
> >> > > > > > > > > > + JNIEnv *jenv = get_jni_env(jthread_self());
> >> > > > > > > > >
> >> > > > > > > > > Ok, I see. I agree that global jni_native_intf should
> >> not be used.
> >> > > > > > > > > There was simple reason why I altered such lines.
> >> Because I changed
> >> > > > > > > > > the type of jni_native_intf and no casting operator
> >> is needed now. To
> >> > > > > > > > > be honest I think get_jni_env(jthread_self()) can be
> >> good as temporary
> >> > > > > > > > > solution only. Lets wait for design of multi VM and
> >> fix it according
> >> > > > > > > > > to it.
> >> > > > > > > >
> >> > > > > > > > While we are in JNI code, we always have the JNIenv (at
> >> least
> >> > > > > > > > initially it comes from Java code). If we consider VM
> >> code as if it
> >> > > > > > > > was a JNI application, then it seems like we should be
> >> just passing
> >> > > > > > > > JNIEnv as a parameter to all functions in VM. Or, we can
> >> be taking it
> >> > > > > > > > from TLS (via jthread_self()), depending on which way is
> >> faster...
> >> > > > > > > Agree.
> >> > > > > > >
> >> > > > > > > >
> >> > > > > > > > >
> >> > > > > > > > > >
> >> > > > > > > > > > 6). And small remarks:
> >> > > > > > > > > > +jint vm_init1(JavaVM_Internal * java_vm,
> >> JavaVMInitArgs * vm_arguments);
> >> > > > > > > > > > +jint vm_init2(JNIEnv_Internal * jni_env);
> >> > > > > > > > > > Could you make names more meaningful, then 1,2,3...?
> >> > > > > > > > > Ok, will do that.
> >> > > > > > > > >
> >> > > > > > > > > >
> >> > > > > > > > > > class VM_thread {
> >> > > > > > > > > > ...
> >> > > > > > > > > > + JNIEnv_Internal * jni_env;
> >> > > > > > > > > > The jthread already has the jni_env pointer, you do
> >> not need to
> >> > > > > > > > > > duplicate it here.
> >> > > > > > > > > > forexample by using
> >> jthread_get_JNI_env(jthread_self());
> >> > > > > > > > >
> >> > > > > > > > > Yes I know. I don't see any problems here. Some times
> >> it is much more
> >> > > > > > > > > convenient to get JNIEnv from VM_thread structure (and
> >> faster) instead
> >> > > > > > > > > of doing jthread_get_JNI_env(jthread_self()). So I
> >> need strong
> >> > > > > > > > > arguments for removing it. Again it seems that should
> >> be addressed in
> >> > > > > > > > > design of multi VM. So lets forget about it for a
> >> while...
> >> > > > > > > >
> >> > > > > > > > I think that the data duplication would always serve as
> >> a potential
> >> > > > > > > > source of errors - while updating one copy of object,
> >> you may forget
> >> > > > > > > > to update the other, often resulting into a strange
> >> behavior of the
> >> > > > > > > > whole application. Let's see what are the specific
> >> performance
> >> > > > > > > > concerns that have to be addressed. To get VM_thread
> >> structure, you
> >> > > > > > > > would eventually go to the TLS, just like
> >> > > > > > > > jthread_get_JNI_env(jthread_self() would do.
> >> > > > > > > If there is already VM_thread structure for some reasons
> >> then there
> >> > > > > > > will be no extra access to TLS. It is definitely much more in
> >> > > > > > > jthread_get_JNI_env(jthread_self() than just one TLS
> >> access and one
> >> > > > > > > dereferncing. I don't think it is a really big problem
> >> now. Do you
> >> > > > > > > agree to look at this later. I guess multi VM
> >> implementation will
> >> > > > > > > alter it in any case.
> >> > > > > > >
> >> > > > > > > Thanks
> >> > > > > > > Evgueni
> >> > > > > > >
> >> > > > > > > >
> >> > > > > > > > Thanks,
> >> > > > > > > > Andrey.
> >> > > > > > > >
> >> > > > > > > > >
> >> > > > > > > > > Evgueni
> >> > > > > > > > > >
> >> > > > > > > > > > Thanks
> >> > > > > > > > > > Artem
> >> > > > > > > > > >
> >> > > > > > > > > > On 9/28/06, Evgueni Brevnov
> >> <ev...@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.
> >> > > > > > > > > > >
> >> > > > > > > > > > > Thanks
> >> > > > > > > > > > > Evgueni
> >> > > > > > > > > > >
> >> > > > > > > > > > > On 9/28/06, Geir Magnusson Jr. <ge...@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
> >> <we...@gmail.com> wrote:
> >> > > > > > > > > > > > >> On 9/26/06, Evgueni Brevnov
> >> <ev...@gmail.com> wrote:
> >> > > > > > > > > > > > >> >
> >> > > > > > > > > > > > >> > On 9/27/06, Andrey Chernyshev
> >> <a....@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
> >> > > > > > > > > > >
> >> > > > > > > > > > >
> >> > > > > > > > > >
> >> > > > > > > > > >
> >> ---------------------------------------------------------------------
> >> > > > > > > > > > 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
> >> > > > > > > > >
> >> > > > > > > > >
> >> > > > > > > >
> >> > > > > > > >
> >> > > > > > > > --
> >> > > > > > > > Andrey Chernyshev
> >> > > > > > > > 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
> >> > > > > >
> >> > > > > >
> >> > > > >
> >> > > > >
> >> > > > > --
> >> > > > > Andrey Chernyshev
> >> > > > > 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
> >> > > >
> >> > > >
> >> > >
> >> > >
> >> > > --
> >> > > Andrey Chernyshev
> >> > > 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
>
>
---------------------------------------------------------------------
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
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
woo hoo! here we go...
Andrey Chernyshev wrote:
> Hi Evgueni,
>
> On 10/4/06, Evgueni Brevnov <ev...@gmail.com> wrote:
>> Hi All,
>>
>> I have attached updated patch to the JIRA. It should resolve remain
>> concerns. Andrey, could you give a green light now?
>
> Thanks for updating the patch! I agree it it can be committed, at
> least signatures look good. 5 revisions seem like more than enough :).
> Anyways, I think the remaining issues can be resolved with additional
> patches. Thanks again for the good work and your patience.
>
> Thanks,
> Andrey.
>
>>
>> Thanks
>> Evgueni
>>
>> On 10/4/06, Evgueni Brevnov <ev...@gmail.com> wrote:
>> > Andrey,
>> >
>> > I see your points. I think both approaches have advantages and
>> > disadvantages. I think it is quite hard to say which approach is
>> > better until we play with one VM only. I still feel like introducing
>> > one more dependence is better than spreading code which deals with
>> > attachment among VM and TM. We really get stuck. OK, just because I
>> > want to move forward I will do required changes to remove
>> > vm_create_jthread from TM. I believe that will resolve all our
>> > disagreements and the patch will be applied soon.
>> >
>> >
>> > Thanks
>> > Evgueni.
>> >
>> > On 10/4/06, Andrey Chernyshev <a....@gmail.com> wrote:
>> > > On 10/3/06, Evgueni Brevnov <ev...@gmail.com> wrote:
>> > > > On 10/3/06, Andrey Chernyshev <a....@gmail.com> wrote:
>> > > > > On 10/2/06, Evgueni Brevnov <ev...@gmail.com> wrote:
>> > > > > > Andrey,
>> > > > > >
>> > > > > > Just to be clear.... I agree with you it is more convenient if
>> > > > > > jthread_create takes JNIEnv instead of JavaVM. It reflects that
>> > > > > > current thread has been attached already. Do you think it
>> makes sense
>> > > > > > to get rid of JNIEnv and use jthread_get_JNI_env in that case?
>> > > > >
>> > > > > The jthread_* layer is designed like if it were a regular JNI
>> > > > > application which is meant to be called from the Java code, hence
>> > > > > every function on that layer receives JNIenv. We can probably
>> get rid
>> > > > > of the JNEnv parameter for jthread_* functions, assuming that
>> TM can
>> > > > > always extract JNIenv for the current thread with
>> > > > > jthread_get_JNI_env().
>> > > > > My only concern would be the performance - once the JNIenv is
>> already
>> > > > > known for the native part of the kernel classes impl, it must be
>> > > > > cheaper to pass JNIEnv to TM as an extra parameter rather than
>> extract
>> > > > > it from the TLS again.
>> > > > > Other than that, I see no strong advantages in keeping JNIEnv
>> parameter.
>> > > > >
>> > > > >
>> > > > > > Regarding jthread_attach. I still didn't get your point....
>> Clarify it
>> > > > > > please if you think jhread_attach should be modified.
>> > > > >
>> > > > > Sorry for being not clear: I think for jthread_attach, we have
>> two options:
>> > > > > 1) Make JNIEnv input parameter - it must be new JNIEnv that VM
>> > > > > pre-allocates for the new Java thread. jthread_attach would just
>> > > > > associate it with the current thread.
>> > > > >
>> > > > > 2) Obtain JNIEnv via vm_attach() callback. In this case, if
>> > > > > vm_attach() callback implementation needs to know for which
>> JavaVM new
>> > > > > JNIenv has to be allocated, then we'll need to add JavaVM as
>> input
>> > > > > parameter for jthread_attach().
>> > > > > I think both options should be fine, (1) would probably keep TM
>> > > > > interface a bit lighter, though (2) may look more closer to
>> the JNI
>> > > > > invocation API idea.
>> > > > > So I think adding JavaVM specifically for jthread_attach may make
>> > > > > sense given the explanation you provided earlier.
>> > > > >
>> > > > > The concern I would have regarding the proposed jthread_attach
>> > > > > implementation is a call to vm_create_jthread() - this call
>> introduces
>> > > > > an extra dependency of TM on vmcore that I'd prefer to be
>> avoided. In
>> > > > > the original version, jthread_attach() was taking jthread
>> argument of
>> > > > > the already prepared j.l.Thread.
>> > > >
>> > > > I understand your concern. Unfortunately I don't see what we can do
>> > > > here. Let me explain. In the beginning you have an unattached
>> native
>> > > > thread. To be able to call java code (which is required for
>> > > > constructing j.l.Thread instance) the thread should be attached
>> first.
>> > > > To be specific it should be attached to VM by calling vm_attach
>> which
>> > > > will return a valid JNIEnv It is valid to use JNI from that moment.
>> > > > Obtained JNIEnv can be used to execute java code and create
>> j.l.Thread
>> > > > instance. Since we do vm_attach in jthread_attach we need to do
>> > > > vm_create_jthread inside jthread_atach as well.
>> > > > Of course it can be an alternative to do vm_attach and
>> > > > vm_create_jthread outside of TM right before jthread_attach.
>> Sure it
>> > > > will reduce one dependence between VM and TM. But it seems like
>> > > > artificial action for me just because of dependency....
>> > >
>> > > Why do you think it is artificial? I would rather prefer not to throw
>> > > vm_attach event from the jthread_attach() call at all than to add
>> > > extra dependency. The idea of jthread layer is a Java face to
>> > > hythread, it is meant to know either a little or nothing about the
>> > > rest of VM. It may be logical to throw vm_attach call from the newly
>> > > created thread, because there is no other way to let know VM the new
>> > > thread is created. VM attach is a different case - VM already knows
>> > > about new Java thread at the time of the AttachCurrentThread call.
>> > >
>> > > >
>> > > > > Do you think it makes sense to replace a single jthread
>> parameter with
>> > > > > a variety of stuff (like thread group, name)? It seems the only
>> > > > > purpose of at these args is to be passed back to VM for
>> > > > > vm_jthread_create(). I would suggest to change this and try doing
>> > > > > either of:
>> > > > > 1) Make signature of jthread_attach with 3 args, JavaVM,
>> jthread and the daemon.
>> > > > Why do you want to pass daemon to TM but thread's name and
>> group. Just
>> > > > because current TM doesn't need such information? What if it is
>> > > > required to get thread name later? Say by introducing
>> > >
>> > > I imagine you need a daemon attribute since the TM is still managing
>> > > the thread daemonality. TM is not managing thread name and group -
>> > > they are all kept on the Java level, hence passing them may be
>> > > excessive.
>> > >
>> > > > jthread_get_name... What will you do in that case? Let me guess you
>> > > > will call j.l.Thread.getName. Right. Ok! In that case I see no
>> > > > problems to call j.l.Thread.isDaemon. Do you agree? So it doesn't
>> > >
>> > > As I suggested earlier, the best way to handle daemonality would
>> > > probably be in pure Java - in j.l.Thread (or j.l.VMThreadManager) or
>> > > whatever. You already lifted it up to the jthread level, but what if
>> > > we can go a little bit higher...
>> > >
>> > > > seems to be a good design to pass only part of the information to
>> > > > jthread_atach. Lets look at the signature of
>> AttachCurrentThread. It
>> > > > takes exactly these three parameters (daemon, name, group)
>> passed as a
>> > > > structure. I was thinking about having exactly the same
>> structure as
>> > > > third parameter of jthread_attach but it occured to be more
>> convinient
>> > > > to pass them seperatly. Although I don't see strong reasons against
>> > > > having a structure a third parameter.
>> > >
>> > > I see. Acually, I would love to keep the jthread_attach func-ty at
>> the
>> > > minimum level which will be needed to handle the only data that TM
>> > > should be aware of. We need a formal boundary between jthread layer
>> > > and vmcore (otherwise jthread won't have a much of sense, one may
>> > > consider it just as a convenience set of functions in vmcore which
>> are
>> > > doing something with threading).
>> > >
>> > > >
>> > > > > 2) Move the implementation of vm_create_jtrhead() to
>> > > > > thread_java_basic.c - could it be written in pure JNI without
>> using
>> > > > > internal VM API like class_alloc_new_object()?
>> > > >
>> > > > Yes, this can be done but it doesn't fix the problem. You still
>> need
>> > > > to know about internal constructor of j.l.Thread
>> > >
>> > > That's bad. Given what you said, now it seems that the most
>> preferable
>> > > sequence for AttachCurrentThread impl still would be like:
>> > > JNIEnv = vm_attach();
>> > > jthread = create_jthread(JNIenv)
>> > > jthread_attach(JNIEnv, jthread) // stores JNIEnv and Hythread into
>> > > TLS, doesn't call vm_attach any longer.
>> > > - this is almost what we had from the beginning...
>> > >
>> > > Thanks,
>> > > Andrey.
>> > >
>> > > >
>> > > >
>> > > > Thanks
>> > > > Evgueni
>> > > > >
>> > > > >
>> > > > > Thanks,
>> > > > > Andrey.
>> > > > >
>> > > > > >
>> > > > > > Thank you
>> > > > > > Evgueni
>> > > > > >
>> > > > > > On 10/2/06, Evgueni Brevnov <ev...@gmail.com> wrote:
>> > > > > > > On 9/29/06, Andrey Chernyshev <a....@gmail.com>
>> wrote:
>> > > > > > > > On 9/29/06, Evgueni Brevnov <ev...@gmail.com>
>> wrote:
>> > > > > > > > > Artem,
>> > > > > > > > >
>> > > > > > > > > Thank you for your feedback.... find my inlined.....
>> > > > > > > > >
>> > > > > > > > > On 9/29/06, Artem Aliev <ar...@gmail.com> wrote:
>> > > > > > > > > > Evgueni,
>> > > > > > > > > >
>> > > > > > > > > > I got most of your changes, but still disagree with all
>> > > > > > > > > > hythread/jthread interface changes. Could leave
>> interface unchanged.
>> > > > > > > > > > See following possible solutions, that could solve
>> the same problems
>> > > > > > > > > > without interface changes.
>> > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > > 1) daemon attribute is a java specific. (Andrey
>> mentioned this already).
>> > > > > > > > > > Could you please move it back. to the jthread
>> layer. It is better
>> > > > > > > > > > to rename
>> > > > > > > > > > hythread_wait_for_all_nondaemon_threads() to
>> > > > > > > > > > jthread_wait_for_all_nondaemon_threads().
>> > > > > > > > > Ok, I see no problems to move "daemon" to java layer.
>> In that case:
>> > > > > > > > > 1) I will move
>> hythread_wait_for_all_nondaemon_threads() from
>> > > > > > > > > thread_init.c to one which implements java layer.
>> > > > > > > > > 2) I will move daemon field from HyThread structure.
>> > > > > > > > >
>> > > > > > > > > Agree?
>> > > > > > > >
>> > > > > > > > Sounds good to me.
>> > > > > > >
>> > > > > > > OK, will do that.
>> > > > > > >
>> > > > > > > >
>> > > > > > > >
>> > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > > 2) JavaVM could be retrieved from JNIEnv by
>> jni_get_java_vm(). So
>> > > > > > > > > > let the jthread_create() and others to use JNIEnv
>> (that is passed from
>> > > > > > > > > > java native method).
>> > > > > > > > > > The vm_attach could get old JNI env and create new
>> one for the new thread.
>> > > > > > > > > > The first JNIEnv is created in CreateVM call and
>> could be passed to
>> > > > > > > > > > the first thread at startup.
>> > > > > > > > > No, no, no. I completely disagree with that!!! Why do
>> you like JNIEnv
>> > > > > > > > > but JavaVM. Why do you think that passing JavaVM
>> instead of JNIEnv
>> > > > > > > > > makes TM less modular? I don't see any difference
>> here.... It seems
>> > > > > > > > > for me like a big big hack to grab JNIEnv from another
>> thread and pass
>> > > > > > > > > it to jthread_attach to perform operations in the
>> current thread.
>> > > > > > > >
>> > > > > > > > TM needs to know JNIEnv, mainly for managing the
>> references to
>> > > > > > > > objects, throwing exceptions and calling run() method of
>> a new thread.
>> > > > > > > > JNI spec proposes that JNIEnv is valid within the given
>> thread, this
>> > > > > > > > is why TM holds the JNIEnv pointer at the moment. This
>> is why TM likes
>> > > > > > > > the JNIEnv.
>> > > > > > > >
>> > > > > > > > Having the JNIEnv, one is able to get JavaVM but not
>> vise versa. This
>> > > > > > > > is why TM doesn't like the JavaVM :)
>> > > > > > > I see your point. Only one note this is true for already
>> attached threads...
>> > > > > > >
>> > > > > > > >
>> > > > > > > > I agree with you that there is a design flaw that the
>> JNIEnv is copied
>> > > > > > > > from the parent thread to a child thread during thread
>> creation. I
>> > > > > > > > think it could be resolved via vm_attach() hook - with
>> this event, VM
>> > > > > > > > might tell the TM what the JNIEnv pointer for new thread
>> should be. I
>> > > > > > > > think you did that by extending the vm_attach() call
>> with the JNIEnv**
>> > > > > > > > argument.
>> > > > > > > >
>> > > > > > > > What is not completely clear is, why do you have to pass
>> the JavaVM
>> > > > > > > > forth and back, once from VM to TM, and then back from
>> TM to VM again?
>> > > > > > > >
>> > > > > > > > If you need to know in jthread_attach, which particular
>> VM vm_attach()
>> > > > > > > > event is coming from, you could have vm_attach like
>> > > > > > > > vm_attach(JNIEnv* currentThreadEnv, JNIEnv**
>> newThreadEnv).
>> > > > > > > I'm a little bit confused.....Current thread hasn't been
>> attached yet.
>> > > > > > > So there is no JNIEnv for it yet. How it can be passed as
>> the first
>> > > > > > > parameter to vm_attach()?
>> > > > > > >
>> > > > > > > > Then you will be always able to get the JavaVM from the
>> JNIEnv.
>> > > > > > > > The only difference is that you are currently doing
>> JNIEnv->JavaVM
>> > > > > > > > conversion in the VMThreadManager, but why can't you
>> just do this in
>> > > > > > > > vm_attach() without changing the interface of the TM?
>> > > > > > > > So far JavaVM really looks like an extra knowledge that
>> TM doesn't
>> > > > > > > > have to be aware of.
>> > > > > > > >
>> > > > > > > > > Moreover there is no JNIEnv when main thread attaches
>> to VM. So we
>> > > > > > > > > should either keep it as is or change original design
>> of TM and attach
>> > > > > > > > > thread to VM before attaching it to TM. In that case
>> we will have
>> > > > > > > > > valid JNIEnv which can be passed to jthread_atatch. We
>> need to think
>> > > > > > > > > over it twice before changing something....
>> > > > > > > >
>> > > > > > > > Right. For jthread_attach, JNIenv needs to be changed
>> from being input
>> > > > > > > > parameter to being the output parameter. The way how
>> JNIenv is
>> > > > > > > > obtained by TM should be vm_attach() event.
>> > > > > > > OK, JNIEnv is output parameter. And it obtained by
>> vm_attach(). This
>> > > > > > > is exactly like I do in the patch. What I don't understand
>> is how
>> > > > > > > jthread_attach knows to which VM the thread should be
>> attached? Do you
>> > > > > > > suggest calling vm_attach first to create JNIEnv it pass
>> it to
>> > > > > > > jthread_attach?
>> > > > > > >
>> > > > > > > >
>> > > > > > > > >
>> > > > > > > > >
>> > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > > 4) Original classlib hythread do not use
>> hythread_library_t in arguments,
>> > > > > > > > > > It uses following code:
>> > > > > > > > > >
>> > > > > > > > > > hythread_library_t lib = GLOBAL_DATA
>> (default_library);
>> > > > > > > > > > or
>> > > > > > > > > > hythread_library_t library = thread->library;
>> > > > > > > > > >
>> > > > > > > > > > So could you please use the same mechanism and
>> remove hythread_*_ex >functions.
>> > > > > > > > > Let's see if classlib's hythread needs changing first.
>> It seems for me
>> > > > > > > > > such code prevents us from having multi VM.
>> > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > > 5. You introduce more then one jni env, but still
>> use global variable for it.
>> > > > > > > > > > So all changes like following:
>> > > > > > > > > > - JNIEnv *jenv = (JNIEnv*)jni_native_intf;
>> > > > > > > > > > + JNIEnv *jenv = jni_native_intf;
>> > > > > > > > > >
>> > > > > > > > > > should be like:
>> > > > > > > > > > - JNIEnv *jenv = (JNIEnv*)jni_native_intf;
>> > > > > > > > > > + JNIEnv *jenv = get_jni_env(jthread_self());
>> > > > > > > > >
>> > > > > > > > > Ok, I see. I agree that global jni_native_intf should
>> not be used.
>> > > > > > > > > There was simple reason why I altered such lines.
>> Because I changed
>> > > > > > > > > the type of jni_native_intf and no casting operator
>> is needed now. To
>> > > > > > > > > be honest I think get_jni_env(jthread_self()) can be
>> good as temporary
>> > > > > > > > > solution only. Lets wait for design of multi VM and
>> fix it according
>> > > > > > > > > to it.
>> > > > > > > >
>> > > > > > > > While we are in JNI code, we always have the JNIenv (at
>> least
>> > > > > > > > initially it comes from Java code). If we consider VM
>> code as if it
>> > > > > > > > was a JNI application, then it seems like we should be
>> just passing
>> > > > > > > > JNIEnv as a parameter to all functions in VM. Or, we can
>> be taking it
>> > > > > > > > from TLS (via jthread_self()), depending on which way is
>> faster...
>> > > > > > > Agree.
>> > > > > > >
>> > > > > > > >
>> > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > > 6). And small remarks:
>> > > > > > > > > > +jint vm_init1(JavaVM_Internal * java_vm,
>> JavaVMInitArgs * vm_arguments);
>> > > > > > > > > > +jint vm_init2(JNIEnv_Internal * jni_env);
>> > > > > > > > > > Could you make names more meaningful, then 1,2,3...?
>> > > > > > > > > Ok, will do that.
>> > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > > class VM_thread {
>> > > > > > > > > > ...
>> > > > > > > > > > + JNIEnv_Internal * jni_env;
>> > > > > > > > > > The jthread already has the jni_env pointer, you do
>> not need to
>> > > > > > > > > > duplicate it here.
>> > > > > > > > > > forexample by using
>> jthread_get_JNI_env(jthread_self());
>> > > > > > > > >
>> > > > > > > > > Yes I know. I don't see any problems here. Some times
>> it is much more
>> > > > > > > > > convenient to get JNIEnv from VM_thread structure (and
>> faster) instead
>> > > > > > > > > of doing jthread_get_JNI_env(jthread_self()). So I
>> need strong
>> > > > > > > > > arguments for removing it. Again it seems that should
>> be addressed in
>> > > > > > > > > design of multi VM. So lets forget about it for a
>> while...
>> > > > > > > >
>> > > > > > > > I think that the data duplication would always serve as
>> a potential
>> > > > > > > > source of errors - while updating one copy of object,
>> you may forget
>> > > > > > > > to update the other, often resulting into a strange
>> behavior of the
>> > > > > > > > whole application. Let's see what are the specific
>> performance
>> > > > > > > > concerns that have to be addressed. To get VM_thread
>> structure, you
>> > > > > > > > would eventually go to the TLS, just like
>> > > > > > > > jthread_get_JNI_env(jthread_self() would do.
>> > > > > > > If there is already VM_thread structure for some reasons
>> then there
>> > > > > > > will be no extra access to TLS. It is definitely much more in
>> > > > > > > jthread_get_JNI_env(jthread_self() than just one TLS
>> access and one
>> > > > > > > dereferncing. I don't think it is a really big problem
>> now. Do you
>> > > > > > > agree to look at this later. I guess multi VM
>> implementation will
>> > > > > > > alter it in any case.
>> > > > > > >
>> > > > > > > Thanks
>> > > > > > > Evgueni
>> > > > > > >
>> > > > > > > >
>> > > > > > > > Thanks,
>> > > > > > > > Andrey.
>> > > > > > > >
>> > > > > > > > >
>> > > > > > > > > Evgueni
>> > > > > > > > > >
>> > > > > > > > > > Thanks
>> > > > > > > > > > Artem
>> > > > > > > > > >
>> > > > > > > > > > On 9/28/06, Evgueni Brevnov
>> <ev...@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.
>> > > > > > > > > > >
>> > > > > > > > > > > Thanks
>> > > > > > > > > > > Evgueni
>> > > > > > > > > > >
>> > > > > > > > > > > On 9/28/06, Geir Magnusson Jr. <ge...@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
>> <we...@gmail.com> wrote:
>> > > > > > > > > > > > >> On 9/26/06, Evgueni Brevnov
>> <ev...@gmail.com> wrote:
>> > > > > > > > > > > > >> >
>> > > > > > > > > > > > >> > On 9/27/06, Andrey Chernyshev
>> <a....@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
>> > > > > > > > > > >
>> > > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > >
>> ---------------------------------------------------------------------
>> > > > > > > > > > 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
>> > > > > > > > >
>> > > > > > > > >
>> > > > > > > >
>> > > > > > > >
>> > > > > > > > --
>> > > > > > > > Andrey Chernyshev
>> > > > > > > > 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
>> > > > > >
>> > > > > >
>> > > > >
>> > > > >
>> > > > > --
>> > > > > Andrey Chernyshev
>> > > > > 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
>> > > >
>> > > >
>> > >
>> > >
>> > > --
>> > > Andrey Chernyshev
>> > > 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
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
Posted by Andrey Chernyshev <a....@gmail.com>.
Hi Evgueni,
On 10/4/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> Hi All,
>
> I have attached updated patch to the JIRA. It should resolve remain
> concerns. Andrey, could you give a green light now?
Thanks for updating the patch! I agree it it can be committed, at
least signatures look good. 5 revisions seem like more than enough :).
Anyways, I think the remaining issues can be resolved with additional
patches. Thanks again for the good work and your patience.
Thanks,
Andrey.
>
> Thanks
> Evgueni
>
> On 10/4/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> > Andrey,
> >
> > I see your points. I think both approaches have advantages and
> > disadvantages. I think it is quite hard to say which approach is
> > better until we play with one VM only. I still feel like introducing
> > one more dependence is better than spreading code which deals with
> > attachment among VM and TM. We really get stuck. OK, just because I
> > want to move forward I will do required changes to remove
> > vm_create_jthread from TM. I believe that will resolve all our
> > disagreements and the patch will be applied soon.
> >
> >
> > Thanks
> > Evgueni.
> >
> > On 10/4/06, Andrey Chernyshev <a....@gmail.com> wrote:
> > > On 10/3/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> > > > On 10/3/06, Andrey Chernyshev <a....@gmail.com> wrote:
> > > > > On 10/2/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> > > > > > Andrey,
> > > > > >
> > > > > > Just to be clear.... I agree with you it is more convenient if
> > > > > > jthread_create takes JNIEnv instead of JavaVM. It reflects that
> > > > > > current thread has been attached already. Do you think it makes sense
> > > > > > to get rid of JNIEnv and use jthread_get_JNI_env in that case?
> > > > >
> > > > > The jthread_* layer is designed like if it were a regular JNI
> > > > > application which is meant to be called from the Java code, hence
> > > > > every function on that layer receives JNIenv. We can probably get rid
> > > > > of the JNEnv parameter for jthread_* functions, assuming that TM can
> > > > > always extract JNIenv for the current thread with
> > > > > jthread_get_JNI_env().
> > > > > My only concern would be the performance - once the JNIenv is already
> > > > > known for the native part of the kernel classes impl, it must be
> > > > > cheaper to pass JNIEnv to TM as an extra parameter rather than extract
> > > > > it from the TLS again.
> > > > > Other than that, I see no strong advantages in keeping JNIEnv parameter.
> > > > >
> > > > >
> > > > > > Regarding jthread_attach. I still didn't get your point.... Clarify it
> > > > > > please if you think jhread_attach should be modified.
> > > > >
> > > > > Sorry for being not clear: I think for jthread_attach, we have two options:
> > > > > 1) Make JNIEnv input parameter - it must be new JNIEnv that VM
> > > > > pre-allocates for the new Java thread. jthread_attach would just
> > > > > associate it with the current thread.
> > > > >
> > > > > 2) Obtain JNIEnv via vm_attach() callback. In this case, if
> > > > > vm_attach() callback implementation needs to know for which JavaVM new
> > > > > JNIenv has to be allocated, then we'll need to add JavaVM as input
> > > > > parameter for jthread_attach().
> > > > > I think both options should be fine, (1) would probably keep TM
> > > > > interface a bit lighter, though (2) may look more closer to the JNI
> > > > > invocation API idea.
> > > > > So I think adding JavaVM specifically for jthread_attach may make
> > > > > sense given the explanation you provided earlier.
> > > > >
> > > > > The concern I would have regarding the proposed jthread_attach
> > > > > implementation is a call to vm_create_jthread() - this call introduces
> > > > > an extra dependency of TM on vmcore that I'd prefer to be avoided. In
> > > > > the original version, jthread_attach() was taking jthread argument of
> > > > > the already prepared j.l.Thread.
> > > >
> > > > I understand your concern. Unfortunately I don't see what we can do
> > > > here. Let me explain. In the beginning you have an unattached native
> > > > thread. To be able to call java code (which is required for
> > > > constructing j.l.Thread instance) the thread should be attached first.
> > > > To be specific it should be attached to VM by calling vm_attach which
> > > > will return a valid JNIEnv It is valid to use JNI from that moment.
> > > > Obtained JNIEnv can be used to execute java code and create j.l.Thread
> > > > instance. Since we do vm_attach in jthread_attach we need to do
> > > > vm_create_jthread inside jthread_atach as well.
> > > > Of course it can be an alternative to do vm_attach and
> > > > vm_create_jthread outside of TM right before jthread_attach. Sure it
> > > > will reduce one dependence between VM and TM. But it seems like
> > > > artificial action for me just because of dependency....
> > >
> > > Why do you think it is artificial? I would rather prefer not to throw
> > > vm_attach event from the jthread_attach() call at all than to add
> > > extra dependency. The idea of jthread layer is a Java face to
> > > hythread, it is meant to know either a little or nothing about the
> > > rest of VM. It may be logical to throw vm_attach call from the newly
> > > created thread, because there is no other way to let know VM the new
> > > thread is created. VM attach is a different case - VM already knows
> > > about new Java thread at the time of the AttachCurrentThread call.
> > >
> > > >
> > > > > Do you think it makes sense to replace a single jthread parameter with
> > > > > a variety of stuff (like thread group, name)? It seems the only
> > > > > purpose of at these args is to be passed back to VM for
> > > > > vm_jthread_create(). I would suggest to change this and try doing
> > > > > either of:
> > > > > 1) Make signature of jthread_attach with 3 args, JavaVM, jthread and the daemon.
> > > > Why do you want to pass daemon to TM but thread's name and group. Just
> > > > because current TM doesn't need such information? What if it is
> > > > required to get thread name later? Say by introducing
> > >
> > > I imagine you need a daemon attribute since the TM is still managing
> > > the thread daemonality. TM is not managing thread name and group -
> > > they are all kept on the Java level, hence passing them may be
> > > excessive.
> > >
> > > > jthread_get_name... What will you do in that case? Let me guess you
> > > > will call j.l.Thread.getName. Right. Ok! In that case I see no
> > > > problems to call j.l.Thread.isDaemon. Do you agree? So it doesn't
> > >
> > > As I suggested earlier, the best way to handle daemonality would
> > > probably be in pure Java - in j.l.Thread (or j.l.VMThreadManager) or
> > > whatever. You already lifted it up to the jthread level, but what if
> > > we can go a little bit higher...
> > >
> > > > seems to be a good design to pass only part of the information to
> > > > jthread_atach. Lets look at the signature of AttachCurrentThread. It
> > > > takes exactly these three parameters (daemon, name, group) passed as a
> > > > structure. I was thinking about having exactly the same structure as
> > > > third parameter of jthread_attach but it occured to be more convinient
> > > > to pass them seperatly. Although I don't see strong reasons against
> > > > having a structure a third parameter.
> > >
> > > I see. Acually, I would love to keep the jthread_attach func-ty at the
> > > minimum level which will be needed to handle the only data that TM
> > > should be aware of. We need a formal boundary between jthread layer
> > > and vmcore (otherwise jthread won't have a much of sense, one may
> > > consider it just as a convenience set of functions in vmcore which are
> > > doing something with threading).
> > >
> > > >
> > > > > 2) Move the implementation of vm_create_jtrhead() to
> > > > > thread_java_basic.c - could it be written in pure JNI without using
> > > > > internal VM API like class_alloc_new_object()?
> > > >
> > > > Yes, this can be done but it doesn't fix the problem. You still need
> > > > to know about internal constructor of j.l.Thread
> > >
> > > That's bad. Given what you said, now it seems that the most preferable
> > > sequence for AttachCurrentThread impl still would be like:
> > > JNIEnv = vm_attach();
> > > jthread = create_jthread(JNIenv)
> > > jthread_attach(JNIEnv, jthread) // stores JNIEnv and Hythread into
> > > TLS, doesn't call vm_attach any longer.
> > > - this is almost what we had from the beginning...
> > >
> > > Thanks,
> > > Andrey.
> > >
> > > >
> > > >
> > > > Thanks
> > > > Evgueni
> > > > >
> > > > >
> > > > > Thanks,
> > > > > Andrey.
> > > > >
> > > > > >
> > > > > > Thank you
> > > > > > Evgueni
> > > > > >
> > > > > > On 10/2/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> > > > > > > On 9/29/06, Andrey Chernyshev <a....@gmail.com> wrote:
> > > > > > > > On 9/29/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> > > > > > > > > Artem,
> > > > > > > > >
> > > > > > > > > Thank you for your feedback.... find my inlined.....
> > > > > > > > >
> > > > > > > > > On 9/29/06, Artem Aliev <ar...@gmail.com> wrote:
> > > > > > > > > > Evgueni,
> > > > > > > > > >
> > > > > > > > > > I got most of your changes, but still disagree with all
> > > > > > > > > > hythread/jthread interface changes. Could leave interface unchanged.
> > > > > > > > > > See following possible solutions, that could solve the same problems
> > > > > > > > > > without interface changes.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > 1) daemon attribute is a java specific. (Andrey mentioned this already).
> > > > > > > > > > Could you please move it back. to the jthread layer. It is better
> > > > > > > > > > to rename
> > > > > > > > > > hythread_wait_for_all_nondaemon_threads() to
> > > > > > > > > > jthread_wait_for_all_nondaemon_threads().
> > > > > > > > > Ok, I see no problems to move "daemon" to java layer. In that case:
> > > > > > > > > 1) I will move hythread_wait_for_all_nondaemon_threads() from
> > > > > > > > > thread_init.c to one which implements java layer.
> > > > > > > > > 2) I will move daemon field from HyThread structure.
> > > > > > > > >
> > > > > > > > > Agree?
> > > > > > > >
> > > > > > > > Sounds good to me.
> > > > > > >
> > > > > > > OK, will do that.
> > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > 2) JavaVM could be retrieved from JNIEnv by jni_get_java_vm(). So
> > > > > > > > > > let the jthread_create() and others to use JNIEnv (that is passed from
> > > > > > > > > > java native method).
> > > > > > > > > > The vm_attach could get old JNI env and create new one for the new thread.
> > > > > > > > > > The first JNIEnv is created in CreateVM call and could be passed to
> > > > > > > > > > the first thread at startup.
> > > > > > > > > No, no, no. I completely disagree with that!!! Why do you like JNIEnv
> > > > > > > > > but JavaVM. Why do you think that passing JavaVM instead of JNIEnv
> > > > > > > > > makes TM less modular? I don't see any difference here.... It seems
> > > > > > > > > for me like a big big hack to grab JNIEnv from another thread and pass
> > > > > > > > > it to jthread_attach to perform operations in the current thread.
> > > > > > > >
> > > > > > > > TM needs to know JNIEnv, mainly for managing the references to
> > > > > > > > objects, throwing exceptions and calling run() method of a new thread.
> > > > > > > > JNI spec proposes that JNIEnv is valid within the given thread, this
> > > > > > > > is why TM holds the JNIEnv pointer at the moment. This is why TM likes
> > > > > > > > the JNIEnv.
> > > > > > > >
> > > > > > > > Having the JNIEnv, one is able to get JavaVM but not vise versa. This
> > > > > > > > is why TM doesn't like the JavaVM :)
> > > > > > > I see your point. Only one note this is true for already attached threads...
> > > > > > >
> > > > > > > >
> > > > > > > > I agree with you that there is a design flaw that the JNIEnv is copied
> > > > > > > > from the parent thread to a child thread during thread creation. I
> > > > > > > > think it could be resolved via vm_attach() hook - with this event, VM
> > > > > > > > might tell the TM what the JNIEnv pointer for new thread should be. I
> > > > > > > > think you did that by extending the vm_attach() call with the JNIEnv**
> > > > > > > > argument.
> > > > > > > >
> > > > > > > > What is not completely clear is, why do you have to pass the JavaVM
> > > > > > > > forth and back, once from VM to TM, and then back from TM to VM again?
> > > > > > > >
> > > > > > > > If you need to know in jthread_attach, which particular VM vm_attach()
> > > > > > > > event is coming from, you could have vm_attach like
> > > > > > > > vm_attach(JNIEnv* currentThreadEnv, JNIEnv** newThreadEnv).
> > > > > > > I'm a little bit confused.....Current thread hasn't been attached yet.
> > > > > > > So there is no JNIEnv for it yet. How it can be passed as the first
> > > > > > > parameter to vm_attach()?
> > > > > > >
> > > > > > > > Then you will be always able to get the JavaVM from the JNIEnv.
> > > > > > > > The only difference is that you are currently doing JNIEnv->JavaVM
> > > > > > > > conversion in the VMThreadManager, but why can't you just do this in
> > > > > > > > vm_attach() without changing the interface of the TM?
> > > > > > > > So far JavaVM really looks like an extra knowledge that TM doesn't
> > > > > > > > have to be aware of.
> > > > > > > >
> > > > > > > > > Moreover there is no JNIEnv when main thread attaches to VM. So we
> > > > > > > > > should either keep it as is or change original design of TM and attach
> > > > > > > > > thread to VM before attaching it to TM. In that case we will have
> > > > > > > > > valid JNIEnv which can be passed to jthread_atatch. We need to think
> > > > > > > > > over it twice before changing something....
> > > > > > > >
> > > > > > > > Right. For jthread_attach, JNIenv needs to be changed from being input
> > > > > > > > parameter to being the output parameter. The way how JNIenv is
> > > > > > > > obtained by TM should be vm_attach() event.
> > > > > > > OK, JNIEnv is output parameter. And it obtained by vm_attach(). This
> > > > > > > is exactly like I do in the patch. What I don't understand is how
> > > > > > > jthread_attach knows to which VM the thread should be attached? Do you
> > > > > > > suggest calling vm_attach first to create JNIEnv it pass it to
> > > > > > > jthread_attach?
> > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > 4) Original classlib hythread do not use hythread_library_t in arguments,
> > > > > > > > > > It uses following code:
> > > > > > > > > >
> > > > > > > > > > hythread_library_t lib = GLOBAL_DATA (default_library);
> > > > > > > > > > or
> > > > > > > > > > hythread_library_t library = thread->library;
> > > > > > > > > >
> > > > > > > > > > So could you please use the same mechanism and remove hythread_*_ex >functions.
> > > > > > > > > Let's see if classlib's hythread needs changing first. It seems for me
> > > > > > > > > such code prevents us from having multi VM.
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > 5. You introduce more then one jni env, but still use global variable for it.
> > > > > > > > > > So all changes like following:
> > > > > > > > > > - JNIEnv *jenv = (JNIEnv*)jni_native_intf;
> > > > > > > > > > + JNIEnv *jenv = jni_native_intf;
> > > > > > > > > >
> > > > > > > > > > should be like:
> > > > > > > > > > - JNIEnv *jenv = (JNIEnv*)jni_native_intf;
> > > > > > > > > > + JNIEnv *jenv = get_jni_env(jthread_self());
> > > > > > > > >
> > > > > > > > > Ok, I see. I agree that global jni_native_intf should not be used.
> > > > > > > > > There was simple reason why I altered such lines. Because I changed
> > > > > > > > > the type of jni_native_intf and no casting operator is needed now. To
> > > > > > > > > be honest I think get_jni_env(jthread_self()) can be good as temporary
> > > > > > > > > solution only. Lets wait for design of multi VM and fix it according
> > > > > > > > > to it.
> > > > > > > >
> > > > > > > > While we are in JNI code, we always have the JNIenv (at least
> > > > > > > > initially it comes from Java code). If we consider VM code as if it
> > > > > > > > was a JNI application, then it seems like we should be just passing
> > > > > > > > JNIEnv as a parameter to all functions in VM. Or, we can be taking it
> > > > > > > > from TLS (via jthread_self()), depending on which way is faster...
> > > > > > > Agree.
> > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > 6). And small remarks:
> > > > > > > > > > +jint vm_init1(JavaVM_Internal * java_vm, JavaVMInitArgs * vm_arguments);
> > > > > > > > > > +jint vm_init2(JNIEnv_Internal * jni_env);
> > > > > > > > > > Could you make names more meaningful, then 1,2,3...?
> > > > > > > > > Ok, will do that.
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > class VM_thread {
> > > > > > > > > > ...
> > > > > > > > > > + JNIEnv_Internal * jni_env;
> > > > > > > > > > The jthread already has the jni_env pointer, you do not need to
> > > > > > > > > > duplicate it here.
> > > > > > > > > > forexample by using jthread_get_JNI_env(jthread_self());
> > > > > > > > >
> > > > > > > > > Yes I know. I don't see any problems here. Some times it is much more
> > > > > > > > > convenient to get JNIEnv from VM_thread structure (and faster) instead
> > > > > > > > > of doing jthread_get_JNI_env(jthread_self()). So I need strong
> > > > > > > > > arguments for removing it. Again it seems that should be addressed in
> > > > > > > > > design of multi VM. So lets forget about it for a while...
> > > > > > > >
> > > > > > > > I think that the data duplication would always serve as a potential
> > > > > > > > source of errors - while updating one copy of object, you may forget
> > > > > > > > to update the other, often resulting into a strange behavior of the
> > > > > > > > whole application. Let's see what are the specific performance
> > > > > > > > concerns that have to be addressed. To get VM_thread structure, you
> > > > > > > > would eventually go to the TLS, just like
> > > > > > > > jthread_get_JNI_env(jthread_self() would do.
> > > > > > > If there is already VM_thread structure for some reasons then there
> > > > > > > will be no extra access to TLS. It is definitely much more in
> > > > > > > jthread_get_JNI_env(jthread_self() than just one TLS access and one
> > > > > > > dereferncing. I don't think it is a really big problem now. Do you
> > > > > > > agree to look at this later. I guess multi VM implementation will
> > > > > > > alter it in any case.
> > > > > > >
> > > > > > > Thanks
> > > > > > > Evgueni
> > > > > > >
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > Andrey.
> > > > > > > >
> > > > > > > > >
> > > > > > > > > Evgueni
> > > > > > > > > >
> > > > > > > > > > Thanks
> > > > > > > > > > Artem
> > > > > > > > > >
> > > > > > > > > > On 9/28/06, Evgueni Brevnov <ev...@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.
> > > > > > > > > > >
> > > > > > > > > > > Thanks
> > > > > > > > > > > Evgueni
> > > > > > > > > > >
> > > > > > > > > > > On 9/28/06, Geir Magnusson Jr. <ge...@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 <we...@gmail.com> wrote:
> > > > > > > > > > > > >> On 9/26/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> > > > > > > > > > > > >> >
> > > > > > > > > > > > >> > On 9/27/06, Andrey Chernyshev <a....@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
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > ---------------------------------------------------------------------
> > > > > > > > > > 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
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Andrey Chernyshev
> > > > > > > > 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
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Andrey Chernyshev
> > > > > 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
> > > >
> > > >
> > >
> > >
> > > --
> > > Andrey Chernyshev
> > > 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
>
>
--
Andrey Chernyshev
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
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
Posted by Artem Aliev <ar...@gmail.com>.
+1 from me
Artem
On 10/5/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> can we get a green light from Andrey and any others in the conversation?
>
> geir
>
>
> Evgueni Brevnov wrote:
> > Hi,
> >
> > I'm working on restoring cunit tests. I already made a good progress
> > in that direction. So I expect to have it done soon....
> >
> > Evgueni
> >
> > On 10/4/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> >> On 10/4/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> >> > I assume you intend that only the latest patch is applied?
> >> Yes. invocation_api.5.patch only.
> >> > (And I assume that it would apply cleanly to SVN HEAD)
> >> I believe so.
> >>
> >> Evgueni
> >> >
> >> > geir
> >> >
> >> > Evgueni Brevnov wrote:
> >> > > Hi All,
> >> > >
> >> > > I have attached updated patch to the JIRA. It should resolve remain
> >> > > concerns. Andrey, could you give a green light now?
> >> > >
> >> > > Thanks
> >> > > Evgueni
> >> > >
> >> > > On 10/4/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> >> > >> Andrey,
> >> > >>
> >> > >> I see your points. I think both approaches have advantages and
> >> > >> disadvantages. I think it is quite hard to say which approach is
> >> > >> better until we play with one VM only. I still feel like introducing
> >> > >> one more dependence is better than spreading code which deals with
> >> > >> attachment among VM and TM. We really get stuck. OK, just because I
> >> > >> want to move forward I will do required changes to remove
> >> > >> vm_create_jthread from TM. I believe that will resolve all our
> >> > >> disagreements and the patch will be applied soon.
> >> > >>
> >> > >>
> >> > >> Thanks
> >> > >> Evgueni.
> >> > >>
> >> > >> On 10/4/06, Andrey Chernyshev <a....@gmail.com> wrote:
> >> > >> > On 10/3/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> >> > >> > > On 10/3/06, Andrey Chernyshev <a....@gmail.com> wrote:
> >> > >> > > > On 10/2/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> >> > >> > > > > Andrey,
> >> > >> > > > >
> >> > >> > > > > Just to be clear.... I agree with you it is more
> >> convenient if
> >> > >> > > > > jthread_create takes JNIEnv instead of JavaVM. It
> >> reflects that
> >> > >> > > > > current thread has been attached already. Do you think it
> >> > >> makes sense
> >> > >> > > > > to get rid of JNIEnv and use jthread_get_JNI_env in that
> >> case?
> >> > >> > > >
> >> > >> > > > The jthread_* layer is designed like if it were a regular JNI
> >> > >> > > > application which is meant to be called from the Java code,
> >> hence
> >> > >> > > > every function on that layer receives JNIenv. We can probably
> >> > >> get rid
> >> > >> > > > of the JNEnv parameter for jthread_* functions, assuming
> >> that TM
> >> > >> can
> >> > >> > > > always extract JNIenv for the current thread with
> >> > >> > > > jthread_get_JNI_env().
> >> > >> > > > My only concern would be the performance - once the JNIenv is
> >> > >> already
> >> > >> > > > known for the native part of the kernel classes impl, it
> >> must be
> >> > >> > > > cheaper to pass JNIEnv to TM as an extra parameter rather than
> >> > >> extract
> >> > >> > > > it from the TLS again.
> >> > >> > > > Other than that, I see no strong advantages in keeping JNIEnv
> >> > >> parameter.
> >> > >> > > >
> >> > >> > > >
> >> > >> > > > > Regarding jthread_attach. I still didn't get your point....
> >> > >> Clarify it
> >> > >> > > > > please if you think jhread_attach should be modified.
> >> > >> > > >
> >> > >> > > > Sorry for being not clear: I think for jthread_attach, we have
> >> > >> two options:
> >> > >> > > > 1) Make JNIEnv input parameter - it must be new JNIEnv that VM
> >> > >> > > > pre-allocates for the new Java thread. jthread_attach
> >> would just
> >> > >> > > > associate it with the current thread.
> >> > >> > > >
> >> > >> > > > 2) Obtain JNIEnv via vm_attach() callback. In this case, if
> >> > >> > > > vm_attach() callback implementation needs to know for which
> >> > >> JavaVM new
> >> > >> > > > JNIenv has to be allocated, then we'll need to add JavaVM
> >> as input
> >> > >> > > > parameter for jthread_attach().
> >> > >> > > > I think both options should be fine, (1) would probably
> >> keep TM
> >> > >> > > > interface a bit lighter, though (2) may look more closer to
> >> the JNI
> >> > >> > > > invocation API idea.
> >> > >> > > > So I think adding JavaVM specifically for jthread_attach
> >> may make
> >> > >> > > > sense given the explanation you provided earlier.
> >> > >> > > >
> >> > >> > > > The concern I would have regarding the proposed jthread_attach
> >> > >> > > > implementation is a call to vm_create_jthread() - this call
> >> > >> introduces
> >> > >> > > > an extra dependency of TM on vmcore that I'd prefer to be
> >> > >> avoided. In
> >> > >> > > > the original version, jthread_attach() was taking jthread
> >> > >> argument of
> >> > >> > > > the already prepared j.l.Thread.
> >> > >> > >
> >> > >> > > I understand your concern. Unfortunately I don't see what we
> >> can do
> >> > >> > > here. Let me explain. In the beginning you have an unattached
> >> native
> >> > >> > > thread. To be able to call java code (which is required for
> >> > >> > > constructing j.l.Thread instance) the thread should be attached
> >> > >> first.
> >> > >> > > To be specific it should be attached to VM by calling
> >> vm_attach which
> >> > >> > > will return a valid JNIEnv It is valid to use JNI from that
> >> moment.
> >> > >> > > Obtained JNIEnv can be used to execute java code and create
> >> > >> j.l.Thread
> >> > >> > > instance. Since we do vm_attach in jthread_attach we need to do
> >> > >> > > vm_create_jthread inside jthread_atach as well.
> >> > >> > > Of course it can be an alternative to do vm_attach and
> >> > >> > > vm_create_jthread outside of TM right before jthread_attach.
> >> Sure it
> >> > >> > > will reduce one dependence between VM and TM. But it seems like
> >> > >> > > artificial action for me just because of dependency....
> >> > >> >
> >> > >> > Why do you think it is artificial? I would rather prefer not to
> >> throw
> >> > >> > vm_attach event from the jthread_attach() call at all than to add
> >> > >> > extra dependency. The idea of jthread layer is a Java face to
> >> > >> > hythread, it is meant to know either a little or nothing about the
> >> > >> > rest of VM. It may be logical to throw vm_attach call from the
> >> newly
> >> > >> > created thread, because there is no other way to let know VM
> >> the new
> >> > >> > thread is created. VM attach is a different case - VM already
> >> knows
> >> > >> > about new Java thread at the time of the AttachCurrentThread call.
> >> > >> >
> >> > >> > >
> >> > >> > > > Do you think it makes sense to replace a single jthread
> >> > >> parameter with
> >> > >> > > > a variety of stuff (like thread group, name)? It seems the
> >> only
> >> > >> > > > purpose of at these args is to be passed back to VM for
> >> > >> > > > vm_jthread_create(). I would suggest to change this and try
> >> doing
> >> > >> > > > either of:
> >> > >> > > > 1) Make signature of jthread_attach with 3 args, JavaVM,
> >> jthread
> >> > >> and the daemon.
> >> > >> > > Why do you want to pass daemon to TM but thread's name and
> >> group.
> >> > >> Just
> >> > >> > > because current TM doesn't need such information? What if it is
> >> > >> > > required to get thread name later? Say by introducing
> >> > >> >
> >> > >> > I imagine you need a daemon attribute since the TM is still
> >> managing
> >> > >> > the thread daemonality. TM is not managing thread name and group -
> >> > >> > they are all kept on the Java level, hence passing them may be
> >> > >> > excessive.
> >> > >> >
> >> > >> > > jthread_get_name... What will you do in that case? Let me
> >> guess you
> >> > >> > > will call j.l.Thread.getName. Right. Ok! In that case I see no
> >> > >> > > problems to call j.l.Thread.isDaemon. Do you agree? So it
> >> doesn't
> >> > >> >
> >> > >> > As I suggested earlier, the best way to handle daemonality would
> >> > >> > probably be in pure Java - in j.l.Thread (or
> >> j.l.VMThreadManager) or
> >> > >> > whatever. You already lifted it up to the jthread level, but
> >> what if
> >> > >> > we can go a little bit higher...
> >> > >> >
> >> > >> > > seems to be a good design to pass only part of the
> >> information to
> >> > >> > > jthread_atach. Lets look at the signature of
> >> AttachCurrentThread. It
> >> > >> > > takes exactly these three parameters (daemon, name, group)
> >> passed
> >> > >> as a
> >> > >> > > structure. I was thinking about having exactly the same
> >> structure as
> >> > >> > > third parameter of jthread_attach but it occured to be more
> >> > >> convinient
> >> > >> > > to pass them seperatly. Although I don't see strong reasons
> >> against
> >> > >> > > having a structure a third parameter.
> >> > >> >
> >> > >> > I see. Acually, I would love to keep the jthread_attach func-ty
> >> at the
> >> > >> > minimum level which will be needed to handle the only data that TM
> >> > >> > should be aware of. We need a formal boundary between jthread
> >> layer
> >> > >> > and vmcore (otherwise jthread won't have a much of sense, one may
> >> > >> > consider it just as a convenience set of functions in vmcore
> >> which are
> >> > >> > doing something with threading).
> >> > >> >
> >> > >> > >
> >> > >> > > > 2) Move the implementation of vm_create_jtrhead() to
> >> > >> > > > thread_java_basic.c - could it be written in pure JNI
> >> without using
> >> > >> > > > internal VM API like class_alloc_new_object()?
> >> > >> > >
> >> > >> > > Yes, this can be done but it doesn't fix the problem. You
> >> still need
> >> > >> > > to know about internal constructor of j.l.Thread
> >> > >> >
> >> > >> > That's bad. Given what you said, now it seems that the most
> >> preferable
> >> > >> > sequence for AttachCurrentThread impl still would be like:
> >> > >> > JNIEnv = vm_attach();
> >> > >> > jthread = create_jthread(JNIenv)
> >> > >> > jthread_attach(JNIEnv, jthread) // stores JNIEnv and Hythread into
> >> > >> > TLS, doesn't call vm_attach any longer.
> >> > >> > - this is almost what we had from the beginning...
> >> > >> >
> >> > >> > Thanks,
> >> > >> > Andrey.
> >> > >> >
> >> > >> > >
> >> > >> > >
> >> > >> > > Thanks
> >> > >> > > Evgueni
> >> > >> > > >
> >> > >> > > >
> >> > >> > > > Thanks,
> >> > >> > > > Andrey.
> >> > >> > > >
> >> > >> > > > >
> >> > >> > > > > Thank you
> >> > >> > > > > Evgueni
> >> > >> > > > >
> >> > >> > > > > On 10/2/06, Evgueni Brevnov <ev...@gmail.com>
> >> wrote:
> >> > >> > > > > > On 9/29/06, Andrey Chernyshev
> >> <a....@gmail.com> wrote:
> >> > >> > > > > > > On 9/29/06, Evgueni Brevnov <ev...@gmail.com>
> >> > >> wrote:
> >> > >> > > > > > > > Artem,
> >> > >> > > > > > > >
> >> > >> > > > > > > > Thank you for your feedback.... find my inlined.....
> >> > >> > > > > > > >
> >> > >> > > > > > > > On 9/29/06, Artem Aliev <ar...@gmail.com> wrote:
> >> > >> > > > > > > > > Evgueni,
> >> > >> > > > > > > > >
> >> > >> > > > > > > > > I got most of your changes, but still disagree
> >> with all
> >> > >> > > > > > > > > hythread/jthread interface changes. Could leave
> >> > >> interface unchanged.
> >> > >> > > > > > > > > See following possible solutions, that could
> >> solve the
> >> > >> same problems
> >> > >> > > > > > > > > without interface changes.
> >> > >> > > > > > > > >
> >> > >> > > > > > > > >
> >> > >> > > > > > > > > 1) daemon attribute is a java specific. (Andrey
> >> > >> mentioned this already).
> >> > >> > > > > > > > > Could you please move it back. to the jthread
> >> layer.
> >> > >> It is better
> >> > >> > > > > > > > > to rename
> >> > >> > > > > > > > > hythread_wait_for_all_nondaemon_threads() to
> >> > >> > > > > > > > > jthread_wait_for_all_nondaemon_threads().
> >> > >> > > > > > > > Ok, I see no problems to move "daemon" to java
> >> layer. In
> >> > >> that case:
> >> > >> > > > > > > > 1) I will move
> >> hythread_wait_for_all_nondaemon_threads()
> >> > >> from
> >> > >> > > > > > > > thread_init.c to one which implements java layer.
> >> > >> > > > > > > > 2) I will move daemon field from HyThread structure.
> >> > >> > > > > > > >
> >> > >> > > > > > > > Agree?
> >> > >> > > > > > >
> >> > >> > > > > > > Sounds good to me.
> >> > >> > > > > >
> >> > >> > > > > > OK, will do that.
> >> > >> > > > > >
> >> > >> > > > > > >
> >> > >> > > > > > >
> >> > >> > > > > > > >
> >> > >> > > > > > > > >
> >> > >> > > > > > > > > 2) JavaVM could be retrieved from JNIEnv by
> >> > >> jni_get_java_vm(). So
> >> > >> > > > > > > > > let the jthread_create() and others to use JNIEnv
> >> > >> (that is passed from
> >> > >> > > > > > > > > java native method).
> >> > >> > > > > > > > > The vm_attach could get old JNI env and create
> >> new one
> >> > >> for the new thread.
> >> > >> > > > > > > > > The first JNIEnv is created in CreateVM call and
> >> could
> >> > >> be passed to
> >> > >> > > > > > > > > the first thread at startup.
> >> > >> > > > > > > > No, no, no. I completely disagree with that!!! Why do
> >> > >> you like JNIEnv
> >> > >> > > > > > > > but JavaVM. Why do you think that passing JavaVM
> >> instead
> >> > >> of JNIEnv
> >> > >> > > > > > > > makes TM less modular? I don't see any difference
> >> > >> here.... It seems
> >> > >> > > > > > > > for me like a big big hack to grab JNIEnv from another
> >> > >> thread and pass
> >> > >> > > > > > > > it to jthread_attach to perform operations in the
> >> > >> current thread.
> >> > >> > > > > > >
> >> > >> > > > > > > TM needs to know JNIEnv, mainly for managing the
> >> > >> references to
> >> > >> > > > > > > objects, throwing exceptions and calling run() method
> >> of a
> >> > >> new thread.
> >> > >> > > > > > > JNI spec proposes that JNIEnv is valid within the given
> >> > >> thread, this
> >> > >> > > > > > > is why TM holds the JNIEnv pointer at the moment.
> >> This is
> >> > >> why TM likes
> >> > >> > > > > > > the JNIEnv.
> >> > >> > > > > > >
> >> > >> > > > > > > Having the JNIEnv, one is able to get JavaVM but not
> >> vise
> >> > >> versa. This
> >> > >> > > > > > > is why TM doesn't like the JavaVM :)
> >> > >> > > > > > I see your point. Only one note this is true for already
> >> > >> attached threads...
> >> > >> > > > > >
> >> > >> > > > > > >
> >> > >> > > > > > > I agree with you that there is a design flaw that the
> >> > >> JNIEnv is copied
> >> > >> > > > > > > from the parent thread to a child thread during thread
> >> > >> creation. I
> >> > >> > > > > > > think it could be resolved via vm_attach() hook - with
> >> > >> this event, VM
> >> > >> > > > > > > might tell the TM what the JNIEnv pointer for new thread
> >> > >> should be. I
> >> > >> > > > > > > think you did that by extending the vm_attach() call
> >> with
> >> > >> the JNIEnv**
> >> > >> > > > > > > argument.
> >> > >> > > > > > >
> >> > >> > > > > > > What is not completely clear is, why do you have to pass
> >> > >> the JavaVM
> >> > >> > > > > > > forth and back, once from VM to TM, and then back
> >> from TM
> >> > >> to VM again?
> >> > >> > > > > > >
> >> > >> > > > > > > If you need to know in jthread_attach, which
> >> particular VM
> >> > >> vm_attach()
> >> > >> > > > > > > event is coming from, you could have vm_attach like
> >> > >> > > > > > > vm_attach(JNIEnv* currentThreadEnv, JNIEnv**
> >> newThreadEnv).
> >> > >> > > > > > I'm a little bit confused.....Current thread hasn't been
> >> > >> attached yet.
> >> > >> > > > > > So there is no JNIEnv for it yet. How it can be passed as
> >> > >> the first
> >> > >> > > > > > parameter to vm_attach()?
> >> > >> > > > > >
> >> > >> > > > > > > Then you will be always able to get the JavaVM from the
> >> > >> JNIEnv.
> >> > >> > > > > > > The only difference is that you are currently doing
> >> > >> JNIEnv->JavaVM
> >> > >> > > > > > > conversion in the VMThreadManager, but why can't you
> >> just
> >> > >> do this in
> >> > >> > > > > > > vm_attach() without changing the interface of the TM?
> >> > >> > > > > > > So far JavaVM really looks like an extra knowledge
> >> that TM
> >> > >> doesn't
> >> > >> > > > > > > have to be aware of.
> >> > >> > > > > > >
> >> > >> > > > > > > > Moreover there is no JNIEnv when main thread
> >> attaches to
> >> > >> VM. So we
> >> > >> > > > > > > > should either keep it as is or change original
> >> design of
> >> > >> TM and attach
> >> > >> > > > > > > > thread to VM before attaching it to TM. In that
> >> case we
> >> > >> will have
> >> > >> > > > > > > > valid JNIEnv which can be passed to jthread_atatch. We
> >> > >> need to think
> >> > >> > > > > > > > over it twice before changing something....
> >> > >> > > > > > >
> >> > >> > > > > > > Right. For jthread_attach, JNIenv needs to be changed
> >> from
> >> > >> being input
> >> > >> > > > > > > parameter to being the output parameter. The way how
> >> > >> JNIenv is
> >> > >> > > > > > > obtained by TM should be vm_attach() event.
> >> > >> > > > > > OK, JNIEnv is output parameter. And it obtained by
> >> > >> vm_attach(). This
> >> > >> > > > > > is exactly like I do in the patch. What I don't understand
> >> > >> is how
> >> > >> > > > > > jthread_attach knows to which VM the thread should be
> >> > >> attached? Do you
> >> > >> > > > > > suggest calling vm_attach first to create JNIEnv it
> >> pass it to
> >> > >> > > > > > jthread_attach?
> >> > >> > > > > >
> >> > >> > > > > > >
> >> > >> > > > > > > >
> >> > >> > > > > > > >
> >> > >> > > > > > > >
> >> > >> > > > > > > > >
> >> > >> > > > > > > > >
> >> > >> > > > > > > > > 4) Original classlib hythread do not use
> >> > >> hythread_library_t in arguments,
> >> > >> > > > > > > > > It uses following code:
> >> > >> > > > > > > > >
> >> > >> > > > > > > > > hythread_library_t lib = GLOBAL_DATA
> >> (default_library);
> >> > >> > > > > > > > > or
> >> > >> > > > > > > > > hythread_library_t library = thread->library;
> >> > >> > > > > > > > >
> >> > >> > > > > > > > > So could you please use the same mechanism and
> >> remove
> >> > >> hythread_*_ex >functions.
> >> > >> > > > > > > > Let's see if classlib's hythread needs changing first.
> >> > >> It seems for me
> >> > >> > > > > > > > such code prevents us from having multi VM.
> >> > >> > > > > > > >
> >> > >> > > > > > > > >
> >> > >> > > > > > > > > 5. You introduce more then one jni env, but still
> >> use
> >> > >> global variable for it.
> >> > >> > > > > > > > > So all changes like following:
> >> > >> > > > > > > > > - JNIEnv *jenv = (JNIEnv*)jni_native_intf;
> >> > >> > > > > > > > > + JNIEnv *jenv = jni_native_intf;
> >> > >> > > > > > > > >
> >> > >> > > > > > > > > should be like:
> >> > >> > > > > > > > > - JNIEnv *jenv = (JNIEnv*)jni_native_intf;
> >> > >> > > > > > > > > + JNIEnv *jenv = get_jni_env(jthread_self());
> >> > >> > > > > > > >
> >> > >> > > > > > > > Ok, I see. I agree that global jni_native_intf should
> >> > >> not be used.
> >> > >> > > > > > > > There was simple reason why I altered such lines.
> >> > >> Because I changed
> >> > >> > > > > > > > the type of jni_native_intf and no casting
> >> operator is
> >> > >> needed now. To
> >> > >> > > > > > > > be honest I think get_jni_env(jthread_self()) can be
> >> > >> good as temporary
> >> > >> > > > > > > > solution only. Lets wait for design of multi VM and
> >> fix
> >> > >> it according
> >> > >> > > > > > > > to it.
> >> > >> > > > > > >
> >> > >> > > > > > > While we are in JNI code, we always have the JNIenv
> >> (at least
> >> > >> > > > > > > initially it comes from Java code). If we consider VM
> >> code
> >> > >> as if it
> >> > >> > > > > > > was a JNI application, then it seems like we should be
> >> > >> just passing
> >> > >> > > > > > > JNIEnv as a parameter to all functions in VM. Or, we can
> >> > >> be taking it
> >> > >> > > > > > > from TLS (via jthread_self()), depending on which way is
> >> > >> faster...
> >> > >> > > > > > Agree.
> >> > >> > > > > >
> >> > >> > > > > > >
> >> > >> > > > > > > >
> >> > >> > > > > > > > >
> >> > >> > > > > > > > > 6). And small remarks:
> >> > >> > > > > > > > > +jint vm_init1(JavaVM_Internal * java_vm,
> >> > >> JavaVMInitArgs * vm_arguments);
> >> > >> > > > > > > > > +jint vm_init2(JNIEnv_Internal * jni_env);
> >> > >> > > > > > > > > Could you make names more meaningful, then 1,2,3...?
> >> > >> > > > > > > > Ok, will do that.
> >> > >> > > > > > > >
> >> > >> > > > > > > > >
> >> > >> > > > > > > > > class VM_thread {
> >> > >> > > > > > > > > ...
> >> > >> > > > > > > > > + JNIEnv_Internal * jni_env;
> >> > >> > > > > > > > > The jthread already has the jni_env pointer, you do
> >> > >> not need to
> >> > >> > > > > > > > > duplicate it here.
> >> > >> > > > > > > > > forexample by using
> >> jthread_get_JNI_env(jthread_self());
> >> > >> > > > > > > >
> >> > >> > > > > > > > Yes I know. I don't see any problems here. Some
> >> times it
> >> > >> is much more
> >> > >> > > > > > > > convenient to get JNIEnv from VM_thread structure (and
> >> > >> faster) instead
> >> > >> > > > > > > > of doing jthread_get_JNI_env(jthread_self()). So I
> >> need
> >> > >> strong
> >> > >> > > > > > > > arguments for removing it. Again it seems that
> >> should be
> >> > >> addressed in
> >> > >> > > > > > > > design of multi VM. So lets forget about it for a
> >> while...
> >> > >> > > > > > >
> >> > >> > > > > > > I think that the data duplication would always serve
> >> as a
> >> > >> potential
> >> > >> > > > > > > source of errors - while updating one copy of object,
> >> you
> >> > >> may forget
> >> > >> > > > > > > to update the other, often resulting into a strange
> >> > >> behavior of the
> >> > >> > > > > > > whole application. Let's see what are the specific
> >> > >> performance
> >> > >> > > > > > > concerns that have to be addressed. To get VM_thread
> >> > >> structure, you
> >> > >> > > > > > > would eventually go to the TLS, just like
> >> > >> > > > > > > jthread_get_JNI_env(jthread_self() would do.
> >> > >> > > > > > If there is already VM_thread structure for some reasons
> >> > >> then there
> >> > >> > > > > > will be no extra access to TLS. It is definitely much
> >> more in
> >> > >> > > > > > jthread_get_JNI_env(jthread_self() than just one TLS
> >> access
> >> > >> and one
> >> > >> > > > > > dereferncing. I don't think it is a really big problem
> >> now.
> >> > >> Do you
> >> > >> > > > > > agree to look at this later. I guess multi VM
> >> implementation
> >> > >> will
> >> > >> > > > > > alter it in any case.
> >> > >> > > > > >
> >> > >> > > > > > Thanks
> >> > >> > > > > > Evgueni
> >> > >> > > > > >
> >> > >> > > > > > >
> >> > >> > > > > > > Thanks,
> >> > >> > > > > > > Andrey.
> >> > >> > > > > > >
> >> > >> > > > > > > >
> >> > >> > > > > > > > Evgueni
> >> > >> > > > > > > > >
> >> > >> > > > > > > > > Thanks
> >> > >> > > > > > > > > Artem
> >> > >> > > > > > > > >
> >> > >> > > > > > > > > On 9/28/06, Evgueni Brevnov
> >> > >> <ev...@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.
> >> > >> > > > > > > > > >
> >> > >> > > > > > > > > > Thanks
> >> > >> > > > > > > > > > Evgueni
> >> > >> > > > > > > > > >
> >> > >> > > > > > > > > > On 9/28/06, Geir Magnusson Jr. <ge...@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
> >> > >> <we...@gmail.com> wrote:
> >> > >> > > > > > > > > > > >> On 9/26/06, Evgueni Brevnov
> >> > >> <ev...@gmail.com> wrote:
> >> > >> > > > > > > > > > > >> >
> >> > >> > > > > > > > > > > >> > On 9/27/06, Andrey Chernyshev
> >> > >> <a....@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
> >> > >> > > > > > > > > >
> >> > >> > > > > > > > > >
> >> > >> > > > > > > > >
> >> > >> > > > > > > > >
> >> > >>
> >> ---------------------------------------------------------------------
> >> > >> > > > > > > > > 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
> >> > >> > > > > > > >
> >> > >> > > > > > > >
> >> > >> > > > > > >
> >> > >> > > > > > >
> >> > >> > > > > > > --
> >> > >> > > > > > > Andrey Chernyshev
> >> > >> > > > > > > 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
> >> > >> > > > >
> >> > >> > > > >
> >> > >> > > >
> >> > >> > > >
> >> > >> > > > --
> >> > >> > > > Andrey Chernyshev
> >> > >> > > > 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
> >> > >> > >
> >> > >> > >
> >> > >> >
> >> > >> >
> >> > >> > --
> >> > >> > Andrey Chernyshev
> >> > >> > 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
> >> >
> >> >
> >>
> >
> > ---------------------------------------------------------------------
> > 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
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
can we get a green light from Andrey and any others in the conversation?
geir
Evgueni Brevnov wrote:
> Hi,
>
> I'm working on restoring cunit tests. I already made a good progress
> in that direction. So I expect to have it done soon....
>
> Evgueni
>
> On 10/4/06, Evgueni Brevnov <ev...@gmail.com> wrote:
>> On 10/4/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>> > I assume you intend that only the latest patch is applied?
>> Yes. invocation_api.5.patch only.
>> > (And I assume that it would apply cleanly to SVN HEAD)
>> I believe so.
>>
>> Evgueni
>> >
>> > geir
>> >
>> > Evgueni Brevnov wrote:
>> > > Hi All,
>> > >
>> > > I have attached updated patch to the JIRA. It should resolve remain
>> > > concerns. Andrey, could you give a green light now?
>> > >
>> > > Thanks
>> > > Evgueni
>> > >
>> > > On 10/4/06, Evgueni Brevnov <ev...@gmail.com> wrote:
>> > >> Andrey,
>> > >>
>> > >> I see your points. I think both approaches have advantages and
>> > >> disadvantages. I think it is quite hard to say which approach is
>> > >> better until we play with one VM only. I still feel like introducing
>> > >> one more dependence is better than spreading code which deals with
>> > >> attachment among VM and TM. We really get stuck. OK, just because I
>> > >> want to move forward I will do required changes to remove
>> > >> vm_create_jthread from TM. I believe that will resolve all our
>> > >> disagreements and the patch will be applied soon.
>> > >>
>> > >>
>> > >> Thanks
>> > >> Evgueni.
>> > >>
>> > >> On 10/4/06, Andrey Chernyshev <a....@gmail.com> wrote:
>> > >> > On 10/3/06, Evgueni Brevnov <ev...@gmail.com> wrote:
>> > >> > > On 10/3/06, Andrey Chernyshev <a....@gmail.com> wrote:
>> > >> > > > On 10/2/06, Evgueni Brevnov <ev...@gmail.com> wrote:
>> > >> > > > > Andrey,
>> > >> > > > >
>> > >> > > > > Just to be clear.... I agree with you it is more
>> convenient if
>> > >> > > > > jthread_create takes JNIEnv instead of JavaVM. It
>> reflects that
>> > >> > > > > current thread has been attached already. Do you think it
>> > >> makes sense
>> > >> > > > > to get rid of JNIEnv and use jthread_get_JNI_env in that
>> case?
>> > >> > > >
>> > >> > > > The jthread_* layer is designed like if it were a regular JNI
>> > >> > > > application which is meant to be called from the Java code,
>> hence
>> > >> > > > every function on that layer receives JNIenv. We can probably
>> > >> get rid
>> > >> > > > of the JNEnv parameter for jthread_* functions, assuming
>> that TM
>> > >> can
>> > >> > > > always extract JNIenv for the current thread with
>> > >> > > > jthread_get_JNI_env().
>> > >> > > > My only concern would be the performance - once the JNIenv is
>> > >> already
>> > >> > > > known for the native part of the kernel classes impl, it
>> must be
>> > >> > > > cheaper to pass JNIEnv to TM as an extra parameter rather than
>> > >> extract
>> > >> > > > it from the TLS again.
>> > >> > > > Other than that, I see no strong advantages in keeping JNIEnv
>> > >> parameter.
>> > >> > > >
>> > >> > > >
>> > >> > > > > Regarding jthread_attach. I still didn't get your point....
>> > >> Clarify it
>> > >> > > > > please if you think jhread_attach should be modified.
>> > >> > > >
>> > >> > > > Sorry for being not clear: I think for jthread_attach, we have
>> > >> two options:
>> > >> > > > 1) Make JNIEnv input parameter - it must be new JNIEnv that VM
>> > >> > > > pre-allocates for the new Java thread. jthread_attach
>> would just
>> > >> > > > associate it with the current thread.
>> > >> > > >
>> > >> > > > 2) Obtain JNIEnv via vm_attach() callback. In this case, if
>> > >> > > > vm_attach() callback implementation needs to know for which
>> > >> JavaVM new
>> > >> > > > JNIenv has to be allocated, then we'll need to add JavaVM
>> as input
>> > >> > > > parameter for jthread_attach().
>> > >> > > > I think both options should be fine, (1) would probably
>> keep TM
>> > >> > > > interface a bit lighter, though (2) may look more closer to
>> the JNI
>> > >> > > > invocation API idea.
>> > >> > > > So I think adding JavaVM specifically for jthread_attach
>> may make
>> > >> > > > sense given the explanation you provided earlier.
>> > >> > > >
>> > >> > > > The concern I would have regarding the proposed jthread_attach
>> > >> > > > implementation is a call to vm_create_jthread() - this call
>> > >> introduces
>> > >> > > > an extra dependency of TM on vmcore that I'd prefer to be
>> > >> avoided. In
>> > >> > > > the original version, jthread_attach() was taking jthread
>> > >> argument of
>> > >> > > > the already prepared j.l.Thread.
>> > >> > >
>> > >> > > I understand your concern. Unfortunately I don't see what we
>> can do
>> > >> > > here. Let me explain. In the beginning you have an unattached
>> native
>> > >> > > thread. To be able to call java code (which is required for
>> > >> > > constructing j.l.Thread instance) the thread should be attached
>> > >> first.
>> > >> > > To be specific it should be attached to VM by calling
>> vm_attach which
>> > >> > > will return a valid JNIEnv It is valid to use JNI from that
>> moment.
>> > >> > > Obtained JNIEnv can be used to execute java code and create
>> > >> j.l.Thread
>> > >> > > instance. Since we do vm_attach in jthread_attach we need to do
>> > >> > > vm_create_jthread inside jthread_atach as well.
>> > >> > > Of course it can be an alternative to do vm_attach and
>> > >> > > vm_create_jthread outside of TM right before jthread_attach.
>> Sure it
>> > >> > > will reduce one dependence between VM and TM. But it seems like
>> > >> > > artificial action for me just because of dependency....
>> > >> >
>> > >> > Why do you think it is artificial? I would rather prefer not to
>> throw
>> > >> > vm_attach event from the jthread_attach() call at all than to add
>> > >> > extra dependency. The idea of jthread layer is a Java face to
>> > >> > hythread, it is meant to know either a little or nothing about the
>> > >> > rest of VM. It may be logical to throw vm_attach call from the
>> newly
>> > >> > created thread, because there is no other way to let know VM
>> the new
>> > >> > thread is created. VM attach is a different case - VM already
>> knows
>> > >> > about new Java thread at the time of the AttachCurrentThread call.
>> > >> >
>> > >> > >
>> > >> > > > Do you think it makes sense to replace a single jthread
>> > >> parameter with
>> > >> > > > a variety of stuff (like thread group, name)? It seems the
>> only
>> > >> > > > purpose of at these args is to be passed back to VM for
>> > >> > > > vm_jthread_create(). I would suggest to change this and try
>> doing
>> > >> > > > either of:
>> > >> > > > 1) Make signature of jthread_attach with 3 args, JavaVM,
>> jthread
>> > >> and the daemon.
>> > >> > > Why do you want to pass daemon to TM but thread's name and
>> group.
>> > >> Just
>> > >> > > because current TM doesn't need such information? What if it is
>> > >> > > required to get thread name later? Say by introducing
>> > >> >
>> > >> > I imagine you need a daemon attribute since the TM is still
>> managing
>> > >> > the thread daemonality. TM is not managing thread name and group -
>> > >> > they are all kept on the Java level, hence passing them may be
>> > >> > excessive.
>> > >> >
>> > >> > > jthread_get_name... What will you do in that case? Let me
>> guess you
>> > >> > > will call j.l.Thread.getName. Right. Ok! In that case I see no
>> > >> > > problems to call j.l.Thread.isDaemon. Do you agree? So it
>> doesn't
>> > >> >
>> > >> > As I suggested earlier, the best way to handle daemonality would
>> > >> > probably be in pure Java - in j.l.Thread (or
>> j.l.VMThreadManager) or
>> > >> > whatever. You already lifted it up to the jthread level, but
>> what if
>> > >> > we can go a little bit higher...
>> > >> >
>> > >> > > seems to be a good design to pass only part of the
>> information to
>> > >> > > jthread_atach. Lets look at the signature of
>> AttachCurrentThread. It
>> > >> > > takes exactly these three parameters (daemon, name, group)
>> passed
>> > >> as a
>> > >> > > structure. I was thinking about having exactly the same
>> structure as
>> > >> > > third parameter of jthread_attach but it occured to be more
>> > >> convinient
>> > >> > > to pass them seperatly. Although I don't see strong reasons
>> against
>> > >> > > having a structure a third parameter.
>> > >> >
>> > >> > I see. Acually, I would love to keep the jthread_attach func-ty
>> at the
>> > >> > minimum level which will be needed to handle the only data that TM
>> > >> > should be aware of. We need a formal boundary between jthread
>> layer
>> > >> > and vmcore (otherwise jthread won't have a much of sense, one may
>> > >> > consider it just as a convenience set of functions in vmcore
>> which are
>> > >> > doing something with threading).
>> > >> >
>> > >> > >
>> > >> > > > 2) Move the implementation of vm_create_jtrhead() to
>> > >> > > > thread_java_basic.c - could it be written in pure JNI
>> without using
>> > >> > > > internal VM API like class_alloc_new_object()?
>> > >> > >
>> > >> > > Yes, this can be done but it doesn't fix the problem. You
>> still need
>> > >> > > to know about internal constructor of j.l.Thread
>> > >> >
>> > >> > That's bad. Given what you said, now it seems that the most
>> preferable
>> > >> > sequence for AttachCurrentThread impl still would be like:
>> > >> > JNIEnv = vm_attach();
>> > >> > jthread = create_jthread(JNIenv)
>> > >> > jthread_attach(JNIEnv, jthread) // stores JNIEnv and Hythread into
>> > >> > TLS, doesn't call vm_attach any longer.
>> > >> > - this is almost what we had from the beginning...
>> > >> >
>> > >> > Thanks,
>> > >> > Andrey.
>> > >> >
>> > >> > >
>> > >> > >
>> > >> > > Thanks
>> > >> > > Evgueni
>> > >> > > >
>> > >> > > >
>> > >> > > > Thanks,
>> > >> > > > Andrey.
>> > >> > > >
>> > >> > > > >
>> > >> > > > > Thank you
>> > >> > > > > Evgueni
>> > >> > > > >
>> > >> > > > > On 10/2/06, Evgueni Brevnov <ev...@gmail.com>
>> wrote:
>> > >> > > > > > On 9/29/06, Andrey Chernyshev
>> <a....@gmail.com> wrote:
>> > >> > > > > > > On 9/29/06, Evgueni Brevnov <ev...@gmail.com>
>> > >> wrote:
>> > >> > > > > > > > Artem,
>> > >> > > > > > > >
>> > >> > > > > > > > Thank you for your feedback.... find my inlined.....
>> > >> > > > > > > >
>> > >> > > > > > > > On 9/29/06, Artem Aliev <ar...@gmail.com> wrote:
>> > >> > > > > > > > > Evgueni,
>> > >> > > > > > > > >
>> > >> > > > > > > > > I got most of your changes, but still disagree
>> with all
>> > >> > > > > > > > > hythread/jthread interface changes. Could leave
>> > >> interface unchanged.
>> > >> > > > > > > > > See following possible solutions, that could
>> solve the
>> > >> same problems
>> > >> > > > > > > > > without interface changes.
>> > >> > > > > > > > >
>> > >> > > > > > > > >
>> > >> > > > > > > > > 1) daemon attribute is a java specific. (Andrey
>> > >> mentioned this already).
>> > >> > > > > > > > > Could you please move it back. to the jthread
>> layer.
>> > >> It is better
>> > >> > > > > > > > > to rename
>> > >> > > > > > > > > hythread_wait_for_all_nondaemon_threads() to
>> > >> > > > > > > > > jthread_wait_for_all_nondaemon_threads().
>> > >> > > > > > > > Ok, I see no problems to move "daemon" to java
>> layer. In
>> > >> that case:
>> > >> > > > > > > > 1) I will move
>> hythread_wait_for_all_nondaemon_threads()
>> > >> from
>> > >> > > > > > > > thread_init.c to one which implements java layer.
>> > >> > > > > > > > 2) I will move daemon field from HyThread structure.
>> > >> > > > > > > >
>> > >> > > > > > > > Agree?
>> > >> > > > > > >
>> > >> > > > > > > Sounds good to me.
>> > >> > > > > >
>> > >> > > > > > OK, will do that.
>> > >> > > > > >
>> > >> > > > > > >
>> > >> > > > > > >
>> > >> > > > > > > >
>> > >> > > > > > > > >
>> > >> > > > > > > > > 2) JavaVM could be retrieved from JNIEnv by
>> > >> jni_get_java_vm(). So
>> > >> > > > > > > > > let the jthread_create() and others to use JNIEnv
>> > >> (that is passed from
>> > >> > > > > > > > > java native method).
>> > >> > > > > > > > > The vm_attach could get old JNI env and create
>> new one
>> > >> for the new thread.
>> > >> > > > > > > > > The first JNIEnv is created in CreateVM call and
>> could
>> > >> be passed to
>> > >> > > > > > > > > the first thread at startup.
>> > >> > > > > > > > No, no, no. I completely disagree with that!!! Why do
>> > >> you like JNIEnv
>> > >> > > > > > > > but JavaVM. Why do you think that passing JavaVM
>> instead
>> > >> of JNIEnv
>> > >> > > > > > > > makes TM less modular? I don't see any difference
>> > >> here.... It seems
>> > >> > > > > > > > for me like a big big hack to grab JNIEnv from another
>> > >> thread and pass
>> > >> > > > > > > > it to jthread_attach to perform operations in the
>> > >> current thread.
>> > >> > > > > > >
>> > >> > > > > > > TM needs to know JNIEnv, mainly for managing the
>> > >> references to
>> > >> > > > > > > objects, throwing exceptions and calling run() method
>> of a
>> > >> new thread.
>> > >> > > > > > > JNI spec proposes that JNIEnv is valid within the given
>> > >> thread, this
>> > >> > > > > > > is why TM holds the JNIEnv pointer at the moment.
>> This is
>> > >> why TM likes
>> > >> > > > > > > the JNIEnv.
>> > >> > > > > > >
>> > >> > > > > > > Having the JNIEnv, one is able to get JavaVM but not
>> vise
>> > >> versa. This
>> > >> > > > > > > is why TM doesn't like the JavaVM :)
>> > >> > > > > > I see your point. Only one note this is true for already
>> > >> attached threads...
>> > >> > > > > >
>> > >> > > > > > >
>> > >> > > > > > > I agree with you that there is a design flaw that the
>> > >> JNIEnv is copied
>> > >> > > > > > > from the parent thread to a child thread during thread
>> > >> creation. I
>> > >> > > > > > > think it could be resolved via vm_attach() hook - with
>> > >> this event, VM
>> > >> > > > > > > might tell the TM what the JNIEnv pointer for new thread
>> > >> should be. I
>> > >> > > > > > > think you did that by extending the vm_attach() call
>> with
>> > >> the JNIEnv**
>> > >> > > > > > > argument.
>> > >> > > > > > >
>> > >> > > > > > > What is not completely clear is, why do you have to pass
>> > >> the JavaVM
>> > >> > > > > > > forth and back, once from VM to TM, and then back
>> from TM
>> > >> to VM again?
>> > >> > > > > > >
>> > >> > > > > > > If you need to know in jthread_attach, which
>> particular VM
>> > >> vm_attach()
>> > >> > > > > > > event is coming from, you could have vm_attach like
>> > >> > > > > > > vm_attach(JNIEnv* currentThreadEnv, JNIEnv**
>> newThreadEnv).
>> > >> > > > > > I'm a little bit confused.....Current thread hasn't been
>> > >> attached yet.
>> > >> > > > > > So there is no JNIEnv for it yet. How it can be passed as
>> > >> the first
>> > >> > > > > > parameter to vm_attach()?
>> > >> > > > > >
>> > >> > > > > > > Then you will be always able to get the JavaVM from the
>> > >> JNIEnv.
>> > >> > > > > > > The only difference is that you are currently doing
>> > >> JNIEnv->JavaVM
>> > >> > > > > > > conversion in the VMThreadManager, but why can't you
>> just
>> > >> do this in
>> > >> > > > > > > vm_attach() without changing the interface of the TM?
>> > >> > > > > > > So far JavaVM really looks like an extra knowledge
>> that TM
>> > >> doesn't
>> > >> > > > > > > have to be aware of.
>> > >> > > > > > >
>> > >> > > > > > > > Moreover there is no JNIEnv when main thread
>> attaches to
>> > >> VM. So we
>> > >> > > > > > > > should either keep it as is or change original
>> design of
>> > >> TM and attach
>> > >> > > > > > > > thread to VM before attaching it to TM. In that
>> case we
>> > >> will have
>> > >> > > > > > > > valid JNIEnv which can be passed to jthread_atatch. We
>> > >> need to think
>> > >> > > > > > > > over it twice before changing something....
>> > >> > > > > > >
>> > >> > > > > > > Right. For jthread_attach, JNIenv needs to be changed
>> from
>> > >> being input
>> > >> > > > > > > parameter to being the output parameter. The way how
>> > >> JNIenv is
>> > >> > > > > > > obtained by TM should be vm_attach() event.
>> > >> > > > > > OK, JNIEnv is output parameter. And it obtained by
>> > >> vm_attach(). This
>> > >> > > > > > is exactly like I do in the patch. What I don't understand
>> > >> is how
>> > >> > > > > > jthread_attach knows to which VM the thread should be
>> > >> attached? Do you
>> > >> > > > > > suggest calling vm_attach first to create JNIEnv it
>> pass it to
>> > >> > > > > > jthread_attach?
>> > >> > > > > >
>> > >> > > > > > >
>> > >> > > > > > > >
>> > >> > > > > > > >
>> > >> > > > > > > >
>> > >> > > > > > > > >
>> > >> > > > > > > > >
>> > >> > > > > > > > > 4) Original classlib hythread do not use
>> > >> hythread_library_t in arguments,
>> > >> > > > > > > > > It uses following code:
>> > >> > > > > > > > >
>> > >> > > > > > > > > hythread_library_t lib = GLOBAL_DATA
>> (default_library);
>> > >> > > > > > > > > or
>> > >> > > > > > > > > hythread_library_t library = thread->library;
>> > >> > > > > > > > >
>> > >> > > > > > > > > So could you please use the same mechanism and
>> remove
>> > >> hythread_*_ex >functions.
>> > >> > > > > > > > Let's see if classlib's hythread needs changing first.
>> > >> It seems for me
>> > >> > > > > > > > such code prevents us from having multi VM.
>> > >> > > > > > > >
>> > >> > > > > > > > >
>> > >> > > > > > > > > 5. You introduce more then one jni env, but still
>> use
>> > >> global variable for it.
>> > >> > > > > > > > > So all changes like following:
>> > >> > > > > > > > > - JNIEnv *jenv = (JNIEnv*)jni_native_intf;
>> > >> > > > > > > > > + JNIEnv *jenv = jni_native_intf;
>> > >> > > > > > > > >
>> > >> > > > > > > > > should be like:
>> > >> > > > > > > > > - JNIEnv *jenv = (JNIEnv*)jni_native_intf;
>> > >> > > > > > > > > + JNIEnv *jenv = get_jni_env(jthread_self());
>> > >> > > > > > > >
>> > >> > > > > > > > Ok, I see. I agree that global jni_native_intf should
>> > >> not be used.
>> > >> > > > > > > > There was simple reason why I altered such lines.
>> > >> Because I changed
>> > >> > > > > > > > the type of jni_native_intf and no casting
>> operator is
>> > >> needed now. To
>> > >> > > > > > > > be honest I think get_jni_env(jthread_self()) can be
>> > >> good as temporary
>> > >> > > > > > > > solution only. Lets wait for design of multi VM and
>> fix
>> > >> it according
>> > >> > > > > > > > to it.
>> > >> > > > > > >
>> > >> > > > > > > While we are in JNI code, we always have the JNIenv
>> (at least
>> > >> > > > > > > initially it comes from Java code). If we consider VM
>> code
>> > >> as if it
>> > >> > > > > > > was a JNI application, then it seems like we should be
>> > >> just passing
>> > >> > > > > > > JNIEnv as a parameter to all functions in VM. Or, we can
>> > >> be taking it
>> > >> > > > > > > from TLS (via jthread_self()), depending on which way is
>> > >> faster...
>> > >> > > > > > Agree.
>> > >> > > > > >
>> > >> > > > > > >
>> > >> > > > > > > >
>> > >> > > > > > > > >
>> > >> > > > > > > > > 6). And small remarks:
>> > >> > > > > > > > > +jint vm_init1(JavaVM_Internal * java_vm,
>> > >> JavaVMInitArgs * vm_arguments);
>> > >> > > > > > > > > +jint vm_init2(JNIEnv_Internal * jni_env);
>> > >> > > > > > > > > Could you make names more meaningful, then 1,2,3...?
>> > >> > > > > > > > Ok, will do that.
>> > >> > > > > > > >
>> > >> > > > > > > > >
>> > >> > > > > > > > > class VM_thread {
>> > >> > > > > > > > > ...
>> > >> > > > > > > > > + JNIEnv_Internal * jni_env;
>> > >> > > > > > > > > The jthread already has the jni_env pointer, you do
>> > >> not need to
>> > >> > > > > > > > > duplicate it here.
>> > >> > > > > > > > > forexample by using
>> jthread_get_JNI_env(jthread_self());
>> > >> > > > > > > >
>> > >> > > > > > > > Yes I know. I don't see any problems here. Some
>> times it
>> > >> is much more
>> > >> > > > > > > > convenient to get JNIEnv from VM_thread structure (and
>> > >> faster) instead
>> > >> > > > > > > > of doing jthread_get_JNI_env(jthread_self()). So I
>> need
>> > >> strong
>> > >> > > > > > > > arguments for removing it. Again it seems that
>> should be
>> > >> addressed in
>> > >> > > > > > > > design of multi VM. So lets forget about it for a
>> while...
>> > >> > > > > > >
>> > >> > > > > > > I think that the data duplication would always serve
>> as a
>> > >> potential
>> > >> > > > > > > source of errors - while updating one copy of object,
>> you
>> > >> may forget
>> > >> > > > > > > to update the other, often resulting into a strange
>> > >> behavior of the
>> > >> > > > > > > whole application. Let's see what are the specific
>> > >> performance
>> > >> > > > > > > concerns that have to be addressed. To get VM_thread
>> > >> structure, you
>> > >> > > > > > > would eventually go to the TLS, just like
>> > >> > > > > > > jthread_get_JNI_env(jthread_self() would do.
>> > >> > > > > > If there is already VM_thread structure for some reasons
>> > >> then there
>> > >> > > > > > will be no extra access to TLS. It is definitely much
>> more in
>> > >> > > > > > jthread_get_JNI_env(jthread_self() than just one TLS
>> access
>> > >> and one
>> > >> > > > > > dereferncing. I don't think it is a really big problem
>> now.
>> > >> Do you
>> > >> > > > > > agree to look at this later. I guess multi VM
>> implementation
>> > >> will
>> > >> > > > > > alter it in any case.
>> > >> > > > > >
>> > >> > > > > > Thanks
>> > >> > > > > > Evgueni
>> > >> > > > > >
>> > >> > > > > > >
>> > >> > > > > > > Thanks,
>> > >> > > > > > > Andrey.
>> > >> > > > > > >
>> > >> > > > > > > >
>> > >> > > > > > > > Evgueni
>> > >> > > > > > > > >
>> > >> > > > > > > > > Thanks
>> > >> > > > > > > > > Artem
>> > >> > > > > > > > >
>> > >> > > > > > > > > On 9/28/06, Evgueni Brevnov
>> > >> <ev...@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.
>> > >> > > > > > > > > >
>> > >> > > > > > > > > > Thanks
>> > >> > > > > > > > > > Evgueni
>> > >> > > > > > > > > >
>> > >> > > > > > > > > > On 9/28/06, Geir Magnusson Jr. <ge...@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
>> > >> <we...@gmail.com> wrote:
>> > >> > > > > > > > > > > >> On 9/26/06, Evgueni Brevnov
>> > >> <ev...@gmail.com> wrote:
>> > >> > > > > > > > > > > >> >
>> > >> > > > > > > > > > > >> > On 9/27/06, Andrey Chernyshev
>> > >> <a....@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
>> > >> > > > > > > > > >
>> > >> > > > > > > > > >
>> > >> > > > > > > > >
>> > >> > > > > > > > >
>> > >>
>> ---------------------------------------------------------------------
>> > >> > > > > > > > > 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
>> > >> > > > > > > >
>> > >> > > > > > > >
>> > >> > > > > > >
>> > >> > > > > > >
>> > >> > > > > > > --
>> > >> > > > > > > Andrey Chernyshev
>> > >> > > > > > > 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
>> > >> > > > >
>> > >> > > > >
>> > >> > > >
>> > >> > > >
>> > >> > > > --
>> > >> > > > Andrey Chernyshev
>> > >> > > > 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
>> > >> > >
>> > >> > >
>> > >> >
>> > >> >
>> > >> > --
>> > >> > Andrey Chernyshev
>> > >> > 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
>> >
>> >
>>
>
> ---------------------------------------------------------------------
> 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
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
Posted by Evgueni Brevnov <ev...@gmail.com>.
Hi,
I'm working on restoring cunit tests. I already made a good progress
in that direction. So I expect to have it done soon....
Evgueni
On 10/4/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> On 10/4/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> > I assume you intend that only the latest patch is applied?
> Yes. invocation_api.5.patch only.
> > (And I assume that it would apply cleanly to SVN HEAD)
> I believe so.
>
> Evgueni
> >
> > geir
> >
> > Evgueni Brevnov wrote:
> > > Hi All,
> > >
> > > I have attached updated patch to the JIRA. It should resolve remain
> > > concerns. Andrey, could you give a green light now?
> > >
> > > Thanks
> > > Evgueni
> > >
> > > On 10/4/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> > >> Andrey,
> > >>
> > >> I see your points. I think both approaches have advantages and
> > >> disadvantages. I think it is quite hard to say which approach is
> > >> better until we play with one VM only. I still feel like introducing
> > >> one more dependence is better than spreading code which deals with
> > >> attachment among VM and TM. We really get stuck. OK, just because I
> > >> want to move forward I will do required changes to remove
> > >> vm_create_jthread from TM. I believe that will resolve all our
> > >> disagreements and the patch will be applied soon.
> > >>
> > >>
> > >> Thanks
> > >> Evgueni.
> > >>
> > >> On 10/4/06, Andrey Chernyshev <a....@gmail.com> wrote:
> > >> > On 10/3/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> > >> > > On 10/3/06, Andrey Chernyshev <a....@gmail.com> wrote:
> > >> > > > On 10/2/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> > >> > > > > Andrey,
> > >> > > > >
> > >> > > > > Just to be clear.... I agree with you it is more convenient if
> > >> > > > > jthread_create takes JNIEnv instead of JavaVM. It reflects that
> > >> > > > > current thread has been attached already. Do you think it
> > >> makes sense
> > >> > > > > to get rid of JNIEnv and use jthread_get_JNI_env in that case?
> > >> > > >
> > >> > > > The jthread_* layer is designed like if it were a regular JNI
> > >> > > > application which is meant to be called from the Java code, hence
> > >> > > > every function on that layer receives JNIenv. We can probably
> > >> get rid
> > >> > > > of the JNEnv parameter for jthread_* functions, assuming that TM
> > >> can
> > >> > > > always extract JNIenv for the current thread with
> > >> > > > jthread_get_JNI_env().
> > >> > > > My only concern would be the performance - once the JNIenv is
> > >> already
> > >> > > > known for the native part of the kernel classes impl, it must be
> > >> > > > cheaper to pass JNIEnv to TM as an extra parameter rather than
> > >> extract
> > >> > > > it from the TLS again.
> > >> > > > Other than that, I see no strong advantages in keeping JNIEnv
> > >> parameter.
> > >> > > >
> > >> > > >
> > >> > > > > Regarding jthread_attach. I still didn't get your point....
> > >> Clarify it
> > >> > > > > please if you think jhread_attach should be modified.
> > >> > > >
> > >> > > > Sorry for being not clear: I think for jthread_attach, we have
> > >> two options:
> > >> > > > 1) Make JNIEnv input parameter - it must be new JNIEnv that VM
> > >> > > > pre-allocates for the new Java thread. jthread_attach would just
> > >> > > > associate it with the current thread.
> > >> > > >
> > >> > > > 2) Obtain JNIEnv via vm_attach() callback. In this case, if
> > >> > > > vm_attach() callback implementation needs to know for which
> > >> JavaVM new
> > >> > > > JNIenv has to be allocated, then we'll need to add JavaVM as input
> > >> > > > parameter for jthread_attach().
> > >> > > > I think both options should be fine, (1) would probably keep TM
> > >> > > > interface a bit lighter, though (2) may look more closer to the JNI
> > >> > > > invocation API idea.
> > >> > > > So I think adding JavaVM specifically for jthread_attach may make
> > >> > > > sense given the explanation you provided earlier.
> > >> > > >
> > >> > > > The concern I would have regarding the proposed jthread_attach
> > >> > > > implementation is a call to vm_create_jthread() - this call
> > >> introduces
> > >> > > > an extra dependency of TM on vmcore that I'd prefer to be
> > >> avoided. In
> > >> > > > the original version, jthread_attach() was taking jthread
> > >> argument of
> > >> > > > the already prepared j.l.Thread.
> > >> > >
> > >> > > I understand your concern. Unfortunately I don't see what we can do
> > >> > > here. Let me explain. In the beginning you have an unattached native
> > >> > > thread. To be able to call java code (which is required for
> > >> > > constructing j.l.Thread instance) the thread should be attached
> > >> first.
> > >> > > To be specific it should be attached to VM by calling vm_attach which
> > >> > > will return a valid JNIEnv It is valid to use JNI from that moment.
> > >> > > Obtained JNIEnv can be used to execute java code and create
> > >> j.l.Thread
> > >> > > instance. Since we do vm_attach in jthread_attach we need to do
> > >> > > vm_create_jthread inside jthread_atach as well.
> > >> > > Of course it can be an alternative to do vm_attach and
> > >> > > vm_create_jthread outside of TM right before jthread_attach. Sure it
> > >> > > will reduce one dependence between VM and TM. But it seems like
> > >> > > artificial action for me just because of dependency....
> > >> >
> > >> > Why do you think it is artificial? I would rather prefer not to throw
> > >> > vm_attach event from the jthread_attach() call at all than to add
> > >> > extra dependency. The idea of jthread layer is a Java face to
> > >> > hythread, it is meant to know either a little or nothing about the
> > >> > rest of VM. It may be logical to throw vm_attach call from the newly
> > >> > created thread, because there is no other way to let know VM the new
> > >> > thread is created. VM attach is a different case - VM already knows
> > >> > about new Java thread at the time of the AttachCurrentThread call.
> > >> >
> > >> > >
> > >> > > > Do you think it makes sense to replace a single jthread
> > >> parameter with
> > >> > > > a variety of stuff (like thread group, name)? It seems the only
> > >> > > > purpose of at these args is to be passed back to VM for
> > >> > > > vm_jthread_create(). I would suggest to change this and try doing
> > >> > > > either of:
> > >> > > > 1) Make signature of jthread_attach with 3 args, JavaVM, jthread
> > >> and the daemon.
> > >> > > Why do you want to pass daemon to TM but thread's name and group.
> > >> Just
> > >> > > because current TM doesn't need such information? What if it is
> > >> > > required to get thread name later? Say by introducing
> > >> >
> > >> > I imagine you need a daemon attribute since the TM is still managing
> > >> > the thread daemonality. TM is not managing thread name and group -
> > >> > they are all kept on the Java level, hence passing them may be
> > >> > excessive.
> > >> >
> > >> > > jthread_get_name... What will you do in that case? Let me guess you
> > >> > > will call j.l.Thread.getName. Right. Ok! In that case I see no
> > >> > > problems to call j.l.Thread.isDaemon. Do you agree? So it doesn't
> > >> >
> > >> > As I suggested earlier, the best way to handle daemonality would
> > >> > probably be in pure Java - in j.l.Thread (or j.l.VMThreadManager) or
> > >> > whatever. You already lifted it up to the jthread level, but what if
> > >> > we can go a little bit higher...
> > >> >
> > >> > > seems to be a good design to pass only part of the information to
> > >> > > jthread_atach. Lets look at the signature of AttachCurrentThread. It
> > >> > > takes exactly these three parameters (daemon, name, group) passed
> > >> as a
> > >> > > structure. I was thinking about having exactly the same structure as
> > >> > > third parameter of jthread_attach but it occured to be more
> > >> convinient
> > >> > > to pass them seperatly. Although I don't see strong reasons against
> > >> > > having a structure a third parameter.
> > >> >
> > >> > I see. Acually, I would love to keep the jthread_attach func-ty at the
> > >> > minimum level which will be needed to handle the only data that TM
> > >> > should be aware of. We need a formal boundary between jthread layer
> > >> > and vmcore (otherwise jthread won't have a much of sense, one may
> > >> > consider it just as a convenience set of functions in vmcore which are
> > >> > doing something with threading).
> > >> >
> > >> > >
> > >> > > > 2) Move the implementation of vm_create_jtrhead() to
> > >> > > > thread_java_basic.c - could it be written in pure JNI without using
> > >> > > > internal VM API like class_alloc_new_object()?
> > >> > >
> > >> > > Yes, this can be done but it doesn't fix the problem. You still need
> > >> > > to know about internal constructor of j.l.Thread
> > >> >
> > >> > That's bad. Given what you said, now it seems that the most preferable
> > >> > sequence for AttachCurrentThread impl still would be like:
> > >> > JNIEnv = vm_attach();
> > >> > jthread = create_jthread(JNIenv)
> > >> > jthread_attach(JNIEnv, jthread) // stores JNIEnv and Hythread into
> > >> > TLS, doesn't call vm_attach any longer.
> > >> > - this is almost what we had from the beginning...
> > >> >
> > >> > Thanks,
> > >> > Andrey.
> > >> >
> > >> > >
> > >> > >
> > >> > > Thanks
> > >> > > Evgueni
> > >> > > >
> > >> > > >
> > >> > > > Thanks,
> > >> > > > Andrey.
> > >> > > >
> > >> > > > >
> > >> > > > > Thank you
> > >> > > > > Evgueni
> > >> > > > >
> > >> > > > > On 10/2/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> > >> > > > > > On 9/29/06, Andrey Chernyshev <a....@gmail.com> wrote:
> > >> > > > > > > On 9/29/06, Evgueni Brevnov <ev...@gmail.com>
> > >> wrote:
> > >> > > > > > > > Artem,
> > >> > > > > > > >
> > >> > > > > > > > Thank you for your feedback.... find my inlined.....
> > >> > > > > > > >
> > >> > > > > > > > On 9/29/06, Artem Aliev <ar...@gmail.com> wrote:
> > >> > > > > > > > > Evgueni,
> > >> > > > > > > > >
> > >> > > > > > > > > I got most of your changes, but still disagree with all
> > >> > > > > > > > > hythread/jthread interface changes. Could leave
> > >> interface unchanged.
> > >> > > > > > > > > See following possible solutions, that could solve the
> > >> same problems
> > >> > > > > > > > > without interface changes.
> > >> > > > > > > > >
> > >> > > > > > > > >
> > >> > > > > > > > > 1) daemon attribute is a java specific. (Andrey
> > >> mentioned this already).
> > >> > > > > > > > > Could you please move it back. to the jthread layer.
> > >> It is better
> > >> > > > > > > > > to rename
> > >> > > > > > > > > hythread_wait_for_all_nondaemon_threads() to
> > >> > > > > > > > > jthread_wait_for_all_nondaemon_threads().
> > >> > > > > > > > Ok, I see no problems to move "daemon" to java layer. In
> > >> that case:
> > >> > > > > > > > 1) I will move hythread_wait_for_all_nondaemon_threads()
> > >> from
> > >> > > > > > > > thread_init.c to one which implements java layer.
> > >> > > > > > > > 2) I will move daemon field from HyThread structure.
> > >> > > > > > > >
> > >> > > > > > > > Agree?
> > >> > > > > > >
> > >> > > > > > > Sounds good to me.
> > >> > > > > >
> > >> > > > > > OK, will do that.
> > >> > > > > >
> > >> > > > > > >
> > >> > > > > > >
> > >> > > > > > > >
> > >> > > > > > > > >
> > >> > > > > > > > > 2) JavaVM could be retrieved from JNIEnv by
> > >> jni_get_java_vm(). So
> > >> > > > > > > > > let the jthread_create() and others to use JNIEnv
> > >> (that is passed from
> > >> > > > > > > > > java native method).
> > >> > > > > > > > > The vm_attach could get old JNI env and create new one
> > >> for the new thread.
> > >> > > > > > > > > The first JNIEnv is created in CreateVM call and could
> > >> be passed to
> > >> > > > > > > > > the first thread at startup.
> > >> > > > > > > > No, no, no. I completely disagree with that!!! Why do
> > >> you like JNIEnv
> > >> > > > > > > > but JavaVM. Why do you think that passing JavaVM instead
> > >> of JNIEnv
> > >> > > > > > > > makes TM less modular? I don't see any difference
> > >> here.... It seems
> > >> > > > > > > > for me like a big big hack to grab JNIEnv from another
> > >> thread and pass
> > >> > > > > > > > it to jthread_attach to perform operations in the
> > >> current thread.
> > >> > > > > > >
> > >> > > > > > > TM needs to know JNIEnv, mainly for managing the
> > >> references to
> > >> > > > > > > objects, throwing exceptions and calling run() method of a
> > >> new thread.
> > >> > > > > > > JNI spec proposes that JNIEnv is valid within the given
> > >> thread, this
> > >> > > > > > > is why TM holds the JNIEnv pointer at the moment. This is
> > >> why TM likes
> > >> > > > > > > the JNIEnv.
> > >> > > > > > >
> > >> > > > > > > Having the JNIEnv, one is able to get JavaVM but not vise
> > >> versa. This
> > >> > > > > > > is why TM doesn't like the JavaVM :)
> > >> > > > > > I see your point. Only one note this is true for already
> > >> attached threads...
> > >> > > > > >
> > >> > > > > > >
> > >> > > > > > > I agree with you that there is a design flaw that the
> > >> JNIEnv is copied
> > >> > > > > > > from the parent thread to a child thread during thread
> > >> creation. I
> > >> > > > > > > think it could be resolved via vm_attach() hook - with
> > >> this event, VM
> > >> > > > > > > might tell the TM what the JNIEnv pointer for new thread
> > >> should be. I
> > >> > > > > > > think you did that by extending the vm_attach() call with
> > >> the JNIEnv**
> > >> > > > > > > argument.
> > >> > > > > > >
> > >> > > > > > > What is not completely clear is, why do you have to pass
> > >> the JavaVM
> > >> > > > > > > forth and back, once from VM to TM, and then back from TM
> > >> to VM again?
> > >> > > > > > >
> > >> > > > > > > If you need to know in jthread_attach, which particular VM
> > >> vm_attach()
> > >> > > > > > > event is coming from, you could have vm_attach like
> > >> > > > > > > vm_attach(JNIEnv* currentThreadEnv, JNIEnv** newThreadEnv).
> > >> > > > > > I'm a little bit confused.....Current thread hasn't been
> > >> attached yet.
> > >> > > > > > So there is no JNIEnv for it yet. How it can be passed as
> > >> the first
> > >> > > > > > parameter to vm_attach()?
> > >> > > > > >
> > >> > > > > > > Then you will be always able to get the JavaVM from the
> > >> JNIEnv.
> > >> > > > > > > The only difference is that you are currently doing
> > >> JNIEnv->JavaVM
> > >> > > > > > > conversion in the VMThreadManager, but why can't you just
> > >> do this in
> > >> > > > > > > vm_attach() without changing the interface of the TM?
> > >> > > > > > > So far JavaVM really looks like an extra knowledge that TM
> > >> doesn't
> > >> > > > > > > have to be aware of.
> > >> > > > > > >
> > >> > > > > > > > Moreover there is no JNIEnv when main thread attaches to
> > >> VM. So we
> > >> > > > > > > > should either keep it as is or change original design of
> > >> TM and attach
> > >> > > > > > > > thread to VM before attaching it to TM. In that case we
> > >> will have
> > >> > > > > > > > valid JNIEnv which can be passed to jthread_atatch. We
> > >> need to think
> > >> > > > > > > > over it twice before changing something....
> > >> > > > > > >
> > >> > > > > > > Right. For jthread_attach, JNIenv needs to be changed from
> > >> being input
> > >> > > > > > > parameter to being the output parameter. The way how
> > >> JNIenv is
> > >> > > > > > > obtained by TM should be vm_attach() event.
> > >> > > > > > OK, JNIEnv is output parameter. And it obtained by
> > >> vm_attach(). This
> > >> > > > > > is exactly like I do in the patch. What I don't understand
> > >> is how
> > >> > > > > > jthread_attach knows to which VM the thread should be
> > >> attached? Do you
> > >> > > > > > suggest calling vm_attach first to create JNIEnv it pass it to
> > >> > > > > > jthread_attach?
> > >> > > > > >
> > >> > > > > > >
> > >> > > > > > > >
> > >> > > > > > > >
> > >> > > > > > > >
> > >> > > > > > > > >
> > >> > > > > > > > >
> > >> > > > > > > > > 4) Original classlib hythread do not use
> > >> hythread_library_t in arguments,
> > >> > > > > > > > > It uses following code:
> > >> > > > > > > > >
> > >> > > > > > > > > hythread_library_t lib = GLOBAL_DATA (default_library);
> > >> > > > > > > > > or
> > >> > > > > > > > > hythread_library_t library = thread->library;
> > >> > > > > > > > >
> > >> > > > > > > > > So could you please use the same mechanism and remove
> > >> hythread_*_ex >functions.
> > >> > > > > > > > Let's see if classlib's hythread needs changing first.
> > >> It seems for me
> > >> > > > > > > > such code prevents us from having multi VM.
> > >> > > > > > > >
> > >> > > > > > > > >
> > >> > > > > > > > > 5. You introduce more then one jni env, but still use
> > >> global variable for it.
> > >> > > > > > > > > So all changes like following:
> > >> > > > > > > > > - JNIEnv *jenv = (JNIEnv*)jni_native_intf;
> > >> > > > > > > > > + JNIEnv *jenv = jni_native_intf;
> > >> > > > > > > > >
> > >> > > > > > > > > should be like:
> > >> > > > > > > > > - JNIEnv *jenv = (JNIEnv*)jni_native_intf;
> > >> > > > > > > > > + JNIEnv *jenv = get_jni_env(jthread_self());
> > >> > > > > > > >
> > >> > > > > > > > Ok, I see. I agree that global jni_native_intf should
> > >> not be used.
> > >> > > > > > > > There was simple reason why I altered such lines.
> > >> Because I changed
> > >> > > > > > > > the type of jni_native_intf and no casting operator is
> > >> needed now. To
> > >> > > > > > > > be honest I think get_jni_env(jthread_self()) can be
> > >> good as temporary
> > >> > > > > > > > solution only. Lets wait for design of multi VM and fix
> > >> it according
> > >> > > > > > > > to it.
> > >> > > > > > >
> > >> > > > > > > While we are in JNI code, we always have the JNIenv (at least
> > >> > > > > > > initially it comes from Java code). If we consider VM code
> > >> as if it
> > >> > > > > > > was a JNI application, then it seems like we should be
> > >> just passing
> > >> > > > > > > JNIEnv as a parameter to all functions in VM. Or, we can
> > >> be taking it
> > >> > > > > > > from TLS (via jthread_self()), depending on which way is
> > >> faster...
> > >> > > > > > Agree.
> > >> > > > > >
> > >> > > > > > >
> > >> > > > > > > >
> > >> > > > > > > > >
> > >> > > > > > > > > 6). And small remarks:
> > >> > > > > > > > > +jint vm_init1(JavaVM_Internal * java_vm,
> > >> JavaVMInitArgs * vm_arguments);
> > >> > > > > > > > > +jint vm_init2(JNIEnv_Internal * jni_env);
> > >> > > > > > > > > Could you make names more meaningful, then 1,2,3...?
> > >> > > > > > > > Ok, will do that.
> > >> > > > > > > >
> > >> > > > > > > > >
> > >> > > > > > > > > class VM_thread {
> > >> > > > > > > > > ...
> > >> > > > > > > > > + JNIEnv_Internal * jni_env;
> > >> > > > > > > > > The jthread already has the jni_env pointer, you do
> > >> not need to
> > >> > > > > > > > > duplicate it here.
> > >> > > > > > > > > forexample by using jthread_get_JNI_env(jthread_self());
> > >> > > > > > > >
> > >> > > > > > > > Yes I know. I don't see any problems here. Some times it
> > >> is much more
> > >> > > > > > > > convenient to get JNIEnv from VM_thread structure (and
> > >> faster) instead
> > >> > > > > > > > of doing jthread_get_JNI_env(jthread_self()). So I need
> > >> strong
> > >> > > > > > > > arguments for removing it. Again it seems that should be
> > >> addressed in
> > >> > > > > > > > design of multi VM. So lets forget about it for a while...
> > >> > > > > > >
> > >> > > > > > > I think that the data duplication would always serve as a
> > >> potential
> > >> > > > > > > source of errors - while updating one copy of object, you
> > >> may forget
> > >> > > > > > > to update the other, often resulting into a strange
> > >> behavior of the
> > >> > > > > > > whole application. Let's see what are the specific
> > >> performance
> > >> > > > > > > concerns that have to be addressed. To get VM_thread
> > >> structure, you
> > >> > > > > > > would eventually go to the TLS, just like
> > >> > > > > > > jthread_get_JNI_env(jthread_self() would do.
> > >> > > > > > If there is already VM_thread structure for some reasons
> > >> then there
> > >> > > > > > will be no extra access to TLS. It is definitely much more in
> > >> > > > > > jthread_get_JNI_env(jthread_self() than just one TLS access
> > >> and one
> > >> > > > > > dereferncing. I don't think it is a really big problem now.
> > >> Do you
> > >> > > > > > agree to look at this later. I guess multi VM implementation
> > >> will
> > >> > > > > > alter it in any case.
> > >> > > > > >
> > >> > > > > > Thanks
> > >> > > > > > Evgueni
> > >> > > > > >
> > >> > > > > > >
> > >> > > > > > > Thanks,
> > >> > > > > > > Andrey.
> > >> > > > > > >
> > >> > > > > > > >
> > >> > > > > > > > Evgueni
> > >> > > > > > > > >
> > >> > > > > > > > > Thanks
> > >> > > > > > > > > Artem
> > >> > > > > > > > >
> > >> > > > > > > > > On 9/28/06, Evgueni Brevnov
> > >> <ev...@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.
> > >> > > > > > > > > >
> > >> > > > > > > > > > Thanks
> > >> > > > > > > > > > Evgueni
> > >> > > > > > > > > >
> > >> > > > > > > > > > On 9/28/06, Geir Magnusson Jr. <ge...@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
> > >> <we...@gmail.com> wrote:
> > >> > > > > > > > > > > >> On 9/26/06, Evgueni Brevnov
> > >> <ev...@gmail.com> wrote:
> > >> > > > > > > > > > > >> >
> > >> > > > > > > > > > > >> > On 9/27/06, Andrey Chernyshev
> > >> <a....@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
> > >> > > > > > > > > >
> > >> > > > > > > > > >
> > >> > > > > > > > >
> > >> > > > > > > > >
> > >> ---------------------------------------------------------------------
> > >> > > > > > > > > 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
> > >> > > > > > > >
> > >> > > > > > > >
> > >> > > > > > >
> > >> > > > > > >
> > >> > > > > > > --
> > >> > > > > > > Andrey Chernyshev
> > >> > > > > > > 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
> > >> > > > >
> > >> > > > >
> > >> > > >
> > >> > > >
> > >> > > > --
> > >> > > > Andrey Chernyshev
> > >> > > > 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
> > >> > >
> > >> > >
> > >> >
> > >> >
> > >> > --
> > >> > Andrey Chernyshev
> > >> > 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
> >
> >
>
---------------------------------------------------------------------
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
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
Posted by Evgueni Brevnov <ev...@gmail.com>.
On 10/4/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> I assume you intend that only the latest patch is applied?
Yes. invocation_api.5.patch only.
> (And I assume that it would apply cleanly to SVN HEAD)
I believe so.
Evgueni
>
> geir
>
> Evgueni Brevnov wrote:
> > Hi All,
> >
> > I have attached updated patch to the JIRA. It should resolve remain
> > concerns. Andrey, could you give a green light now?
> >
> > Thanks
> > Evgueni
> >
> > On 10/4/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> >> Andrey,
> >>
> >> I see your points. I think both approaches have advantages and
> >> disadvantages. I think it is quite hard to say which approach is
> >> better until we play with one VM only. I still feel like introducing
> >> one more dependence is better than spreading code which deals with
> >> attachment among VM and TM. We really get stuck. OK, just because I
> >> want to move forward I will do required changes to remove
> >> vm_create_jthread from TM. I believe that will resolve all our
> >> disagreements and the patch will be applied soon.
> >>
> >>
> >> Thanks
> >> Evgueni.
> >>
> >> On 10/4/06, Andrey Chernyshev <a....@gmail.com> wrote:
> >> > On 10/3/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> >> > > On 10/3/06, Andrey Chernyshev <a....@gmail.com> wrote:
> >> > > > On 10/2/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> >> > > > > Andrey,
> >> > > > >
> >> > > > > Just to be clear.... I agree with you it is more convenient if
> >> > > > > jthread_create takes JNIEnv instead of JavaVM. It reflects that
> >> > > > > current thread has been attached already. Do you think it
> >> makes sense
> >> > > > > to get rid of JNIEnv and use jthread_get_JNI_env in that case?
> >> > > >
> >> > > > The jthread_* layer is designed like if it were a regular JNI
> >> > > > application which is meant to be called from the Java code, hence
> >> > > > every function on that layer receives JNIenv. We can probably
> >> get rid
> >> > > > of the JNEnv parameter for jthread_* functions, assuming that TM
> >> can
> >> > > > always extract JNIenv for the current thread with
> >> > > > jthread_get_JNI_env().
> >> > > > My only concern would be the performance - once the JNIenv is
> >> already
> >> > > > known for the native part of the kernel classes impl, it must be
> >> > > > cheaper to pass JNIEnv to TM as an extra parameter rather than
> >> extract
> >> > > > it from the TLS again.
> >> > > > Other than that, I see no strong advantages in keeping JNIEnv
> >> parameter.
> >> > > >
> >> > > >
> >> > > > > Regarding jthread_attach. I still didn't get your point....
> >> Clarify it
> >> > > > > please if you think jhread_attach should be modified.
> >> > > >
> >> > > > Sorry for being not clear: I think for jthread_attach, we have
> >> two options:
> >> > > > 1) Make JNIEnv input parameter - it must be new JNIEnv that VM
> >> > > > pre-allocates for the new Java thread. jthread_attach would just
> >> > > > associate it with the current thread.
> >> > > >
> >> > > > 2) Obtain JNIEnv via vm_attach() callback. In this case, if
> >> > > > vm_attach() callback implementation needs to know for which
> >> JavaVM new
> >> > > > JNIenv has to be allocated, then we'll need to add JavaVM as input
> >> > > > parameter for jthread_attach().
> >> > > > I think both options should be fine, (1) would probably keep TM
> >> > > > interface a bit lighter, though (2) may look more closer to the JNI
> >> > > > invocation API idea.
> >> > > > So I think adding JavaVM specifically for jthread_attach may make
> >> > > > sense given the explanation you provided earlier.
> >> > > >
> >> > > > The concern I would have regarding the proposed jthread_attach
> >> > > > implementation is a call to vm_create_jthread() - this call
> >> introduces
> >> > > > an extra dependency of TM on vmcore that I'd prefer to be
> >> avoided. In
> >> > > > the original version, jthread_attach() was taking jthread
> >> argument of
> >> > > > the already prepared j.l.Thread.
> >> > >
> >> > > I understand your concern. Unfortunately I don't see what we can do
> >> > > here. Let me explain. In the beginning you have an unattached native
> >> > > thread. To be able to call java code (which is required for
> >> > > constructing j.l.Thread instance) the thread should be attached
> >> first.
> >> > > To be specific it should be attached to VM by calling vm_attach which
> >> > > will return a valid JNIEnv It is valid to use JNI from that moment.
> >> > > Obtained JNIEnv can be used to execute java code and create
> >> j.l.Thread
> >> > > instance. Since we do vm_attach in jthread_attach we need to do
> >> > > vm_create_jthread inside jthread_atach as well.
> >> > > Of course it can be an alternative to do vm_attach and
> >> > > vm_create_jthread outside of TM right before jthread_attach. Sure it
> >> > > will reduce one dependence between VM and TM. But it seems like
> >> > > artificial action for me just because of dependency....
> >> >
> >> > Why do you think it is artificial? I would rather prefer not to throw
> >> > vm_attach event from the jthread_attach() call at all than to add
> >> > extra dependency. The idea of jthread layer is a Java face to
> >> > hythread, it is meant to know either a little or nothing about the
> >> > rest of VM. It may be logical to throw vm_attach call from the newly
> >> > created thread, because there is no other way to let know VM the new
> >> > thread is created. VM attach is a different case - VM already knows
> >> > about new Java thread at the time of the AttachCurrentThread call.
> >> >
> >> > >
> >> > > > Do you think it makes sense to replace a single jthread
> >> parameter with
> >> > > > a variety of stuff (like thread group, name)? It seems the only
> >> > > > purpose of at these args is to be passed back to VM for
> >> > > > vm_jthread_create(). I would suggest to change this and try doing
> >> > > > either of:
> >> > > > 1) Make signature of jthread_attach with 3 args, JavaVM, jthread
> >> and the daemon.
> >> > > Why do you want to pass daemon to TM but thread's name and group.
> >> Just
> >> > > because current TM doesn't need such information? What if it is
> >> > > required to get thread name later? Say by introducing
> >> >
> >> > I imagine you need a daemon attribute since the TM is still managing
> >> > the thread daemonality. TM is not managing thread name and group -
> >> > they are all kept on the Java level, hence passing them may be
> >> > excessive.
> >> >
> >> > > jthread_get_name... What will you do in that case? Let me guess you
> >> > > will call j.l.Thread.getName. Right. Ok! In that case I see no
> >> > > problems to call j.l.Thread.isDaemon. Do you agree? So it doesn't
> >> >
> >> > As I suggested earlier, the best way to handle daemonality would
> >> > probably be in pure Java - in j.l.Thread (or j.l.VMThreadManager) or
> >> > whatever. You already lifted it up to the jthread level, but what if
> >> > we can go a little bit higher...
> >> >
> >> > > seems to be a good design to pass only part of the information to
> >> > > jthread_atach. Lets look at the signature of AttachCurrentThread. It
> >> > > takes exactly these three parameters (daemon, name, group) passed
> >> as a
> >> > > structure. I was thinking about having exactly the same structure as
> >> > > third parameter of jthread_attach but it occured to be more
> >> convinient
> >> > > to pass them seperatly. Although I don't see strong reasons against
> >> > > having a structure a third parameter.
> >> >
> >> > I see. Acually, I would love to keep the jthread_attach func-ty at the
> >> > minimum level which will be needed to handle the only data that TM
> >> > should be aware of. We need a formal boundary between jthread layer
> >> > and vmcore (otherwise jthread won't have a much of sense, one may
> >> > consider it just as a convenience set of functions in vmcore which are
> >> > doing something with threading).
> >> >
> >> > >
> >> > > > 2) Move the implementation of vm_create_jtrhead() to
> >> > > > thread_java_basic.c - could it be written in pure JNI without using
> >> > > > internal VM API like class_alloc_new_object()?
> >> > >
> >> > > Yes, this can be done but it doesn't fix the problem. You still need
> >> > > to know about internal constructor of j.l.Thread
> >> >
> >> > That's bad. Given what you said, now it seems that the most preferable
> >> > sequence for AttachCurrentThread impl still would be like:
> >> > JNIEnv = vm_attach();
> >> > jthread = create_jthread(JNIenv)
> >> > jthread_attach(JNIEnv, jthread) // stores JNIEnv and Hythread into
> >> > TLS, doesn't call vm_attach any longer.
> >> > - this is almost what we had from the beginning...
> >> >
> >> > Thanks,
> >> > Andrey.
> >> >
> >> > >
> >> > >
> >> > > Thanks
> >> > > Evgueni
> >> > > >
> >> > > >
> >> > > > Thanks,
> >> > > > Andrey.
> >> > > >
> >> > > > >
> >> > > > > Thank you
> >> > > > > Evgueni
> >> > > > >
> >> > > > > On 10/2/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> >> > > > > > On 9/29/06, Andrey Chernyshev <a....@gmail.com> wrote:
> >> > > > > > > On 9/29/06, Evgueni Brevnov <ev...@gmail.com>
> >> wrote:
> >> > > > > > > > Artem,
> >> > > > > > > >
> >> > > > > > > > Thank you for your feedback.... find my inlined.....
> >> > > > > > > >
> >> > > > > > > > On 9/29/06, Artem Aliev <ar...@gmail.com> wrote:
> >> > > > > > > > > Evgueni,
> >> > > > > > > > >
> >> > > > > > > > > I got most of your changes, but still disagree with all
> >> > > > > > > > > hythread/jthread interface changes. Could leave
> >> interface unchanged.
> >> > > > > > > > > See following possible solutions, that could solve the
> >> same problems
> >> > > > > > > > > without interface changes.
> >> > > > > > > > >
> >> > > > > > > > >
> >> > > > > > > > > 1) daemon attribute is a java specific. (Andrey
> >> mentioned this already).
> >> > > > > > > > > Could you please move it back. to the jthread layer.
> >> It is better
> >> > > > > > > > > to rename
> >> > > > > > > > > hythread_wait_for_all_nondaemon_threads() to
> >> > > > > > > > > jthread_wait_for_all_nondaemon_threads().
> >> > > > > > > > Ok, I see no problems to move "daemon" to java layer. In
> >> that case:
> >> > > > > > > > 1) I will move hythread_wait_for_all_nondaemon_threads()
> >> from
> >> > > > > > > > thread_init.c to one which implements java layer.
> >> > > > > > > > 2) I will move daemon field from HyThread structure.
> >> > > > > > > >
> >> > > > > > > > Agree?
> >> > > > > > >
> >> > > > > > > Sounds good to me.
> >> > > > > >
> >> > > > > > OK, will do that.
> >> > > > > >
> >> > > > > > >
> >> > > > > > >
> >> > > > > > > >
> >> > > > > > > > >
> >> > > > > > > > > 2) JavaVM could be retrieved from JNIEnv by
> >> jni_get_java_vm(). So
> >> > > > > > > > > let the jthread_create() and others to use JNIEnv
> >> (that is passed from
> >> > > > > > > > > java native method).
> >> > > > > > > > > The vm_attach could get old JNI env and create new one
> >> for the new thread.
> >> > > > > > > > > The first JNIEnv is created in CreateVM call and could
> >> be passed to
> >> > > > > > > > > the first thread at startup.
> >> > > > > > > > No, no, no. I completely disagree with that!!! Why do
> >> you like JNIEnv
> >> > > > > > > > but JavaVM. Why do you think that passing JavaVM instead
> >> of JNIEnv
> >> > > > > > > > makes TM less modular? I don't see any difference
> >> here.... It seems
> >> > > > > > > > for me like a big big hack to grab JNIEnv from another
> >> thread and pass
> >> > > > > > > > it to jthread_attach to perform operations in the
> >> current thread.
> >> > > > > > >
> >> > > > > > > TM needs to know JNIEnv, mainly for managing the
> >> references to
> >> > > > > > > objects, throwing exceptions and calling run() method of a
> >> new thread.
> >> > > > > > > JNI spec proposes that JNIEnv is valid within the given
> >> thread, this
> >> > > > > > > is why TM holds the JNIEnv pointer at the moment. This is
> >> why TM likes
> >> > > > > > > the JNIEnv.
> >> > > > > > >
> >> > > > > > > Having the JNIEnv, one is able to get JavaVM but not vise
> >> versa. This
> >> > > > > > > is why TM doesn't like the JavaVM :)
> >> > > > > > I see your point. Only one note this is true for already
> >> attached threads...
> >> > > > > >
> >> > > > > > >
> >> > > > > > > I agree with you that there is a design flaw that the
> >> JNIEnv is copied
> >> > > > > > > from the parent thread to a child thread during thread
> >> creation. I
> >> > > > > > > think it could be resolved via vm_attach() hook - with
> >> this event, VM
> >> > > > > > > might tell the TM what the JNIEnv pointer for new thread
> >> should be. I
> >> > > > > > > think you did that by extending the vm_attach() call with
> >> the JNIEnv**
> >> > > > > > > argument.
> >> > > > > > >
> >> > > > > > > What is not completely clear is, why do you have to pass
> >> the JavaVM
> >> > > > > > > forth and back, once from VM to TM, and then back from TM
> >> to VM again?
> >> > > > > > >
> >> > > > > > > If you need to know in jthread_attach, which particular VM
> >> vm_attach()
> >> > > > > > > event is coming from, you could have vm_attach like
> >> > > > > > > vm_attach(JNIEnv* currentThreadEnv, JNIEnv** newThreadEnv).
> >> > > > > > I'm a little bit confused.....Current thread hasn't been
> >> attached yet.
> >> > > > > > So there is no JNIEnv for it yet. How it can be passed as
> >> the first
> >> > > > > > parameter to vm_attach()?
> >> > > > > >
> >> > > > > > > Then you will be always able to get the JavaVM from the
> >> JNIEnv.
> >> > > > > > > The only difference is that you are currently doing
> >> JNIEnv->JavaVM
> >> > > > > > > conversion in the VMThreadManager, but why can't you just
> >> do this in
> >> > > > > > > vm_attach() without changing the interface of the TM?
> >> > > > > > > So far JavaVM really looks like an extra knowledge that TM
> >> doesn't
> >> > > > > > > have to be aware of.
> >> > > > > > >
> >> > > > > > > > Moreover there is no JNIEnv when main thread attaches to
> >> VM. So we
> >> > > > > > > > should either keep it as is or change original design of
> >> TM and attach
> >> > > > > > > > thread to VM before attaching it to TM. In that case we
> >> will have
> >> > > > > > > > valid JNIEnv which can be passed to jthread_atatch. We
> >> need to think
> >> > > > > > > > over it twice before changing something....
> >> > > > > > >
> >> > > > > > > Right. For jthread_attach, JNIenv needs to be changed from
> >> being input
> >> > > > > > > parameter to being the output parameter. The way how
> >> JNIenv is
> >> > > > > > > obtained by TM should be vm_attach() event.
> >> > > > > > OK, JNIEnv is output parameter. And it obtained by
> >> vm_attach(). This
> >> > > > > > is exactly like I do in the patch. What I don't understand
> >> is how
> >> > > > > > jthread_attach knows to which VM the thread should be
> >> attached? Do you
> >> > > > > > suggest calling vm_attach first to create JNIEnv it pass it to
> >> > > > > > jthread_attach?
> >> > > > > >
> >> > > > > > >
> >> > > > > > > >
> >> > > > > > > >
> >> > > > > > > >
> >> > > > > > > > >
> >> > > > > > > > >
> >> > > > > > > > > 4) Original classlib hythread do not use
> >> hythread_library_t in arguments,
> >> > > > > > > > > It uses following code:
> >> > > > > > > > >
> >> > > > > > > > > hythread_library_t lib = GLOBAL_DATA (default_library);
> >> > > > > > > > > or
> >> > > > > > > > > hythread_library_t library = thread->library;
> >> > > > > > > > >
> >> > > > > > > > > So could you please use the same mechanism and remove
> >> hythread_*_ex >functions.
> >> > > > > > > > Let's see if classlib's hythread needs changing first.
> >> It seems for me
> >> > > > > > > > such code prevents us from having multi VM.
> >> > > > > > > >
> >> > > > > > > > >
> >> > > > > > > > > 5. You introduce more then one jni env, but still use
> >> global variable for it.
> >> > > > > > > > > So all changes like following:
> >> > > > > > > > > - JNIEnv *jenv = (JNIEnv*)jni_native_intf;
> >> > > > > > > > > + JNIEnv *jenv = jni_native_intf;
> >> > > > > > > > >
> >> > > > > > > > > should be like:
> >> > > > > > > > > - JNIEnv *jenv = (JNIEnv*)jni_native_intf;
> >> > > > > > > > > + JNIEnv *jenv = get_jni_env(jthread_self());
> >> > > > > > > >
> >> > > > > > > > Ok, I see. I agree that global jni_native_intf should
> >> not be used.
> >> > > > > > > > There was simple reason why I altered such lines.
> >> Because I changed
> >> > > > > > > > the type of jni_native_intf and no casting operator is
> >> needed now. To
> >> > > > > > > > be honest I think get_jni_env(jthread_self()) can be
> >> good as temporary
> >> > > > > > > > solution only. Lets wait for design of multi VM and fix
> >> it according
> >> > > > > > > > to it.
> >> > > > > > >
> >> > > > > > > While we are in JNI code, we always have the JNIenv (at least
> >> > > > > > > initially it comes from Java code). If we consider VM code
> >> as if it
> >> > > > > > > was a JNI application, then it seems like we should be
> >> just passing
> >> > > > > > > JNIEnv as a parameter to all functions in VM. Or, we can
> >> be taking it
> >> > > > > > > from TLS (via jthread_self()), depending on which way is
> >> faster...
> >> > > > > > Agree.
> >> > > > > >
> >> > > > > > >
> >> > > > > > > >
> >> > > > > > > > >
> >> > > > > > > > > 6). And small remarks:
> >> > > > > > > > > +jint vm_init1(JavaVM_Internal * java_vm,
> >> JavaVMInitArgs * vm_arguments);
> >> > > > > > > > > +jint vm_init2(JNIEnv_Internal * jni_env);
> >> > > > > > > > > Could you make names more meaningful, then 1,2,3...?
> >> > > > > > > > Ok, will do that.
> >> > > > > > > >
> >> > > > > > > > >
> >> > > > > > > > > class VM_thread {
> >> > > > > > > > > ...
> >> > > > > > > > > + JNIEnv_Internal * jni_env;
> >> > > > > > > > > The jthread already has the jni_env pointer, you do
> >> not need to
> >> > > > > > > > > duplicate it here.
> >> > > > > > > > > forexample by using jthread_get_JNI_env(jthread_self());
> >> > > > > > > >
> >> > > > > > > > Yes I know. I don't see any problems here. Some times it
> >> is much more
> >> > > > > > > > convenient to get JNIEnv from VM_thread structure (and
> >> faster) instead
> >> > > > > > > > of doing jthread_get_JNI_env(jthread_self()). So I need
> >> strong
> >> > > > > > > > arguments for removing it. Again it seems that should be
> >> addressed in
> >> > > > > > > > design of multi VM. So lets forget about it for a while...
> >> > > > > > >
> >> > > > > > > I think that the data duplication would always serve as a
> >> potential
> >> > > > > > > source of errors - while updating one copy of object, you
> >> may forget
> >> > > > > > > to update the other, often resulting into a strange
> >> behavior of the
> >> > > > > > > whole application. Let's see what are the specific
> >> performance
> >> > > > > > > concerns that have to be addressed. To get VM_thread
> >> structure, you
> >> > > > > > > would eventually go to the TLS, just like
> >> > > > > > > jthread_get_JNI_env(jthread_self() would do.
> >> > > > > > If there is already VM_thread structure for some reasons
> >> then there
> >> > > > > > will be no extra access to TLS. It is definitely much more in
> >> > > > > > jthread_get_JNI_env(jthread_self() than just one TLS access
> >> and one
> >> > > > > > dereferncing. I don't think it is a really big problem now.
> >> Do you
> >> > > > > > agree to look at this later. I guess multi VM implementation
> >> will
> >> > > > > > alter it in any case.
> >> > > > > >
> >> > > > > > Thanks
> >> > > > > > Evgueni
> >> > > > > >
> >> > > > > > >
> >> > > > > > > Thanks,
> >> > > > > > > Andrey.
> >> > > > > > >
> >> > > > > > > >
> >> > > > > > > > Evgueni
> >> > > > > > > > >
> >> > > > > > > > > Thanks
> >> > > > > > > > > Artem
> >> > > > > > > > >
> >> > > > > > > > > On 9/28/06, Evgueni Brevnov
> >> <ev...@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.
> >> > > > > > > > > >
> >> > > > > > > > > > Thanks
> >> > > > > > > > > > Evgueni
> >> > > > > > > > > >
> >> > > > > > > > > > On 9/28/06, Geir Magnusson Jr. <ge...@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
> >> <we...@gmail.com> wrote:
> >> > > > > > > > > > > >> On 9/26/06, Evgueni Brevnov
> >> <ev...@gmail.com> wrote:
> >> > > > > > > > > > > >> >
> >> > > > > > > > > > > >> > On 9/27/06, Andrey Chernyshev
> >> <a....@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
> >> > > > > > > > > >
> >> > > > > > > > > >
> >> > > > > > > > >
> >> > > > > > > > >
> >> ---------------------------------------------------------------------
> >> > > > > > > > > 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
> >> > > > > > > >
> >> > > > > > > >
> >> > > > > > >
> >> > > > > > >
> >> > > > > > > --
> >> > > > > > > Andrey Chernyshev
> >> > > > > > > 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
> >> > > > >
> >> > > > >
> >> > > >
> >> > > >
> >> > > > --
> >> > > > Andrey Chernyshev
> >> > > > 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
> >> > >
> >> > >
> >> >
> >> >
> >> > --
> >> > Andrey Chernyshev
> >> > 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
>
>
---------------------------------------------------------------------
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
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
I assume you intend that only the latest patch is applied? (And I
assume that it would apply cleanly to SVN HEAD)
geir
Evgueni Brevnov wrote:
> Hi All,
>
> I have attached updated patch to the JIRA. It should resolve remain
> concerns. Andrey, could you give a green light now?
>
> Thanks
> Evgueni
>
> On 10/4/06, Evgueni Brevnov <ev...@gmail.com> wrote:
>> Andrey,
>>
>> I see your points. I think both approaches have advantages and
>> disadvantages. I think it is quite hard to say which approach is
>> better until we play with one VM only. I still feel like introducing
>> one more dependence is better than spreading code which deals with
>> attachment among VM and TM. We really get stuck. OK, just because I
>> want to move forward I will do required changes to remove
>> vm_create_jthread from TM. I believe that will resolve all our
>> disagreements and the patch will be applied soon.
>>
>>
>> Thanks
>> Evgueni.
>>
>> On 10/4/06, Andrey Chernyshev <a....@gmail.com> wrote:
>> > On 10/3/06, Evgueni Brevnov <ev...@gmail.com> wrote:
>> > > On 10/3/06, Andrey Chernyshev <a....@gmail.com> wrote:
>> > > > On 10/2/06, Evgueni Brevnov <ev...@gmail.com> wrote:
>> > > > > Andrey,
>> > > > >
>> > > > > Just to be clear.... I agree with you it is more convenient if
>> > > > > jthread_create takes JNIEnv instead of JavaVM. It reflects that
>> > > > > current thread has been attached already. Do you think it
>> makes sense
>> > > > > to get rid of JNIEnv and use jthread_get_JNI_env in that case?
>> > > >
>> > > > The jthread_* layer is designed like if it were a regular JNI
>> > > > application which is meant to be called from the Java code, hence
>> > > > every function on that layer receives JNIenv. We can probably
>> get rid
>> > > > of the JNEnv parameter for jthread_* functions, assuming that TM
>> can
>> > > > always extract JNIenv for the current thread with
>> > > > jthread_get_JNI_env().
>> > > > My only concern would be the performance - once the JNIenv is
>> already
>> > > > known for the native part of the kernel classes impl, it must be
>> > > > cheaper to pass JNIEnv to TM as an extra parameter rather than
>> extract
>> > > > it from the TLS again.
>> > > > Other than that, I see no strong advantages in keeping JNIEnv
>> parameter.
>> > > >
>> > > >
>> > > > > Regarding jthread_attach. I still didn't get your point....
>> Clarify it
>> > > > > please if you think jhread_attach should be modified.
>> > > >
>> > > > Sorry for being not clear: I think for jthread_attach, we have
>> two options:
>> > > > 1) Make JNIEnv input parameter - it must be new JNIEnv that VM
>> > > > pre-allocates for the new Java thread. jthread_attach would just
>> > > > associate it with the current thread.
>> > > >
>> > > > 2) Obtain JNIEnv via vm_attach() callback. In this case, if
>> > > > vm_attach() callback implementation needs to know for which
>> JavaVM new
>> > > > JNIenv has to be allocated, then we'll need to add JavaVM as input
>> > > > parameter for jthread_attach().
>> > > > I think both options should be fine, (1) would probably keep TM
>> > > > interface a bit lighter, though (2) may look more closer to the JNI
>> > > > invocation API idea.
>> > > > So I think adding JavaVM specifically for jthread_attach may make
>> > > > sense given the explanation you provided earlier.
>> > > >
>> > > > The concern I would have regarding the proposed jthread_attach
>> > > > implementation is a call to vm_create_jthread() - this call
>> introduces
>> > > > an extra dependency of TM on vmcore that I'd prefer to be
>> avoided. In
>> > > > the original version, jthread_attach() was taking jthread
>> argument of
>> > > > the already prepared j.l.Thread.
>> > >
>> > > I understand your concern. Unfortunately I don't see what we can do
>> > > here. Let me explain. In the beginning you have an unattached native
>> > > thread. To be able to call java code (which is required for
>> > > constructing j.l.Thread instance) the thread should be attached
>> first.
>> > > To be specific it should be attached to VM by calling vm_attach which
>> > > will return a valid JNIEnv It is valid to use JNI from that moment.
>> > > Obtained JNIEnv can be used to execute java code and create
>> j.l.Thread
>> > > instance. Since we do vm_attach in jthread_attach we need to do
>> > > vm_create_jthread inside jthread_atach as well.
>> > > Of course it can be an alternative to do vm_attach and
>> > > vm_create_jthread outside of TM right before jthread_attach. Sure it
>> > > will reduce one dependence between VM and TM. But it seems like
>> > > artificial action for me just because of dependency....
>> >
>> > Why do you think it is artificial? I would rather prefer not to throw
>> > vm_attach event from the jthread_attach() call at all than to add
>> > extra dependency. The idea of jthread layer is a Java face to
>> > hythread, it is meant to know either a little or nothing about the
>> > rest of VM. It may be logical to throw vm_attach call from the newly
>> > created thread, because there is no other way to let know VM the new
>> > thread is created. VM attach is a different case - VM already knows
>> > about new Java thread at the time of the AttachCurrentThread call.
>> >
>> > >
>> > > > Do you think it makes sense to replace a single jthread
>> parameter with
>> > > > a variety of stuff (like thread group, name)? It seems the only
>> > > > purpose of at these args is to be passed back to VM for
>> > > > vm_jthread_create(). I would suggest to change this and try doing
>> > > > either of:
>> > > > 1) Make signature of jthread_attach with 3 args, JavaVM, jthread
>> and the daemon.
>> > > Why do you want to pass daemon to TM but thread's name and group.
>> Just
>> > > because current TM doesn't need such information? What if it is
>> > > required to get thread name later? Say by introducing
>> >
>> > I imagine you need a daemon attribute since the TM is still managing
>> > the thread daemonality. TM is not managing thread name and group -
>> > they are all kept on the Java level, hence passing them may be
>> > excessive.
>> >
>> > > jthread_get_name... What will you do in that case? Let me guess you
>> > > will call j.l.Thread.getName. Right. Ok! In that case I see no
>> > > problems to call j.l.Thread.isDaemon. Do you agree? So it doesn't
>> >
>> > As I suggested earlier, the best way to handle daemonality would
>> > probably be in pure Java - in j.l.Thread (or j.l.VMThreadManager) or
>> > whatever. You already lifted it up to the jthread level, but what if
>> > we can go a little bit higher...
>> >
>> > > seems to be a good design to pass only part of the information to
>> > > jthread_atach. Lets look at the signature of AttachCurrentThread. It
>> > > takes exactly these three parameters (daemon, name, group) passed
>> as a
>> > > structure. I was thinking about having exactly the same structure as
>> > > third parameter of jthread_attach but it occured to be more
>> convinient
>> > > to pass them seperatly. Although I don't see strong reasons against
>> > > having a structure a third parameter.
>> >
>> > I see. Acually, I would love to keep the jthread_attach func-ty at the
>> > minimum level which will be needed to handle the only data that TM
>> > should be aware of. We need a formal boundary between jthread layer
>> > and vmcore (otherwise jthread won't have a much of sense, one may
>> > consider it just as a convenience set of functions in vmcore which are
>> > doing something with threading).
>> >
>> > >
>> > > > 2) Move the implementation of vm_create_jtrhead() to
>> > > > thread_java_basic.c - could it be written in pure JNI without using
>> > > > internal VM API like class_alloc_new_object()?
>> > >
>> > > Yes, this can be done but it doesn't fix the problem. You still need
>> > > to know about internal constructor of j.l.Thread
>> >
>> > That's bad. Given what you said, now it seems that the most preferable
>> > sequence for AttachCurrentThread impl still would be like:
>> > JNIEnv = vm_attach();
>> > jthread = create_jthread(JNIenv)
>> > jthread_attach(JNIEnv, jthread) // stores JNIEnv and Hythread into
>> > TLS, doesn't call vm_attach any longer.
>> > - this is almost what we had from the beginning...
>> >
>> > Thanks,
>> > Andrey.
>> >
>> > >
>> > >
>> > > Thanks
>> > > Evgueni
>> > > >
>> > > >
>> > > > Thanks,
>> > > > Andrey.
>> > > >
>> > > > >
>> > > > > Thank you
>> > > > > Evgueni
>> > > > >
>> > > > > On 10/2/06, Evgueni Brevnov <ev...@gmail.com> wrote:
>> > > > > > On 9/29/06, Andrey Chernyshev <a....@gmail.com> wrote:
>> > > > > > > On 9/29/06, Evgueni Brevnov <ev...@gmail.com>
>> wrote:
>> > > > > > > > Artem,
>> > > > > > > >
>> > > > > > > > Thank you for your feedback.... find my inlined.....
>> > > > > > > >
>> > > > > > > > On 9/29/06, Artem Aliev <ar...@gmail.com> wrote:
>> > > > > > > > > Evgueni,
>> > > > > > > > >
>> > > > > > > > > I got most of your changes, but still disagree with all
>> > > > > > > > > hythread/jthread interface changes. Could leave
>> interface unchanged.
>> > > > > > > > > See following possible solutions, that could solve the
>> same problems
>> > > > > > > > > without interface changes.
>> > > > > > > > >
>> > > > > > > > >
>> > > > > > > > > 1) daemon attribute is a java specific. (Andrey
>> mentioned this already).
>> > > > > > > > > Could you please move it back. to the jthread layer.
>> It is better
>> > > > > > > > > to rename
>> > > > > > > > > hythread_wait_for_all_nondaemon_threads() to
>> > > > > > > > > jthread_wait_for_all_nondaemon_threads().
>> > > > > > > > Ok, I see no problems to move "daemon" to java layer. In
>> that case:
>> > > > > > > > 1) I will move hythread_wait_for_all_nondaemon_threads()
>> from
>> > > > > > > > thread_init.c to one which implements java layer.
>> > > > > > > > 2) I will move daemon field from HyThread structure.
>> > > > > > > >
>> > > > > > > > Agree?
>> > > > > > >
>> > > > > > > Sounds good to me.
>> > > > > >
>> > > > > > OK, will do that.
>> > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > > >
>> > > > > > > > >
>> > > > > > > > > 2) JavaVM could be retrieved from JNIEnv by
>> jni_get_java_vm(). So
>> > > > > > > > > let the jthread_create() and others to use JNIEnv
>> (that is passed from
>> > > > > > > > > java native method).
>> > > > > > > > > The vm_attach could get old JNI env and create new one
>> for the new thread.
>> > > > > > > > > The first JNIEnv is created in CreateVM call and could
>> be passed to
>> > > > > > > > > the first thread at startup.
>> > > > > > > > No, no, no. I completely disagree with that!!! Why do
>> you like JNIEnv
>> > > > > > > > but JavaVM. Why do you think that passing JavaVM instead
>> of JNIEnv
>> > > > > > > > makes TM less modular? I don't see any difference
>> here.... It seems
>> > > > > > > > for me like a big big hack to grab JNIEnv from another
>> thread and pass
>> > > > > > > > it to jthread_attach to perform operations in the
>> current thread.
>> > > > > > >
>> > > > > > > TM needs to know JNIEnv, mainly for managing the
>> references to
>> > > > > > > objects, throwing exceptions and calling run() method of a
>> new thread.
>> > > > > > > JNI spec proposes that JNIEnv is valid within the given
>> thread, this
>> > > > > > > is why TM holds the JNIEnv pointer at the moment. This is
>> why TM likes
>> > > > > > > the JNIEnv.
>> > > > > > >
>> > > > > > > Having the JNIEnv, one is able to get JavaVM but not vise
>> versa. This
>> > > > > > > is why TM doesn't like the JavaVM :)
>> > > > > > I see your point. Only one note this is true for already
>> attached threads...
>> > > > > >
>> > > > > > >
>> > > > > > > I agree with you that there is a design flaw that the
>> JNIEnv is copied
>> > > > > > > from the parent thread to a child thread during thread
>> creation. I
>> > > > > > > think it could be resolved via vm_attach() hook - with
>> this event, VM
>> > > > > > > might tell the TM what the JNIEnv pointer for new thread
>> should be. I
>> > > > > > > think you did that by extending the vm_attach() call with
>> the JNIEnv**
>> > > > > > > argument.
>> > > > > > >
>> > > > > > > What is not completely clear is, why do you have to pass
>> the JavaVM
>> > > > > > > forth and back, once from VM to TM, and then back from TM
>> to VM again?
>> > > > > > >
>> > > > > > > If you need to know in jthread_attach, which particular VM
>> vm_attach()
>> > > > > > > event is coming from, you could have vm_attach like
>> > > > > > > vm_attach(JNIEnv* currentThreadEnv, JNIEnv** newThreadEnv).
>> > > > > > I'm a little bit confused.....Current thread hasn't been
>> attached yet.
>> > > > > > So there is no JNIEnv for it yet. How it can be passed as
>> the first
>> > > > > > parameter to vm_attach()?
>> > > > > >
>> > > > > > > Then you will be always able to get the JavaVM from the
>> JNIEnv.
>> > > > > > > The only difference is that you are currently doing
>> JNIEnv->JavaVM
>> > > > > > > conversion in the VMThreadManager, but why can't you just
>> do this in
>> > > > > > > vm_attach() without changing the interface of the TM?
>> > > > > > > So far JavaVM really looks like an extra knowledge that TM
>> doesn't
>> > > > > > > have to be aware of.
>> > > > > > >
>> > > > > > > > Moreover there is no JNIEnv when main thread attaches to
>> VM. So we
>> > > > > > > > should either keep it as is or change original design of
>> TM and attach
>> > > > > > > > thread to VM before attaching it to TM. In that case we
>> will have
>> > > > > > > > valid JNIEnv which can be passed to jthread_atatch. We
>> need to think
>> > > > > > > > over it twice before changing something....
>> > > > > > >
>> > > > > > > Right. For jthread_attach, JNIenv needs to be changed from
>> being input
>> > > > > > > parameter to being the output parameter. The way how
>> JNIenv is
>> > > > > > > obtained by TM should be vm_attach() event.
>> > > > > > OK, JNIEnv is output parameter. And it obtained by
>> vm_attach(). This
>> > > > > > is exactly like I do in the patch. What I don't understand
>> is how
>> > > > > > jthread_attach knows to which VM the thread should be
>> attached? Do you
>> > > > > > suggest calling vm_attach first to create JNIEnv it pass it to
>> > > > > > jthread_attach?
>> > > > > >
>> > > > > > >
>> > > > > > > >
>> > > > > > > >
>> > > > > > > >
>> > > > > > > > >
>> > > > > > > > >
>> > > > > > > > > 4) Original classlib hythread do not use
>> hythread_library_t in arguments,
>> > > > > > > > > It uses following code:
>> > > > > > > > >
>> > > > > > > > > hythread_library_t lib = GLOBAL_DATA (default_library);
>> > > > > > > > > or
>> > > > > > > > > hythread_library_t library = thread->library;
>> > > > > > > > >
>> > > > > > > > > So could you please use the same mechanism and remove
>> hythread_*_ex >functions.
>> > > > > > > > Let's see if classlib's hythread needs changing first.
>> It seems for me
>> > > > > > > > such code prevents us from having multi VM.
>> > > > > > > >
>> > > > > > > > >
>> > > > > > > > > 5. You introduce more then one jni env, but still use
>> global variable for it.
>> > > > > > > > > So all changes like following:
>> > > > > > > > > - JNIEnv *jenv = (JNIEnv*)jni_native_intf;
>> > > > > > > > > + JNIEnv *jenv = jni_native_intf;
>> > > > > > > > >
>> > > > > > > > > should be like:
>> > > > > > > > > - JNIEnv *jenv = (JNIEnv*)jni_native_intf;
>> > > > > > > > > + JNIEnv *jenv = get_jni_env(jthread_self());
>> > > > > > > >
>> > > > > > > > Ok, I see. I agree that global jni_native_intf should
>> not be used.
>> > > > > > > > There was simple reason why I altered such lines.
>> Because I changed
>> > > > > > > > the type of jni_native_intf and no casting operator is
>> needed now. To
>> > > > > > > > be honest I think get_jni_env(jthread_self()) can be
>> good as temporary
>> > > > > > > > solution only. Lets wait for design of multi VM and fix
>> it according
>> > > > > > > > to it.
>> > > > > > >
>> > > > > > > While we are in JNI code, we always have the JNIenv (at least
>> > > > > > > initially it comes from Java code). If we consider VM code
>> as if it
>> > > > > > > was a JNI application, then it seems like we should be
>> just passing
>> > > > > > > JNIEnv as a parameter to all functions in VM. Or, we can
>> be taking it
>> > > > > > > from TLS (via jthread_self()), depending on which way is
>> faster...
>> > > > > > Agree.
>> > > > > >
>> > > > > > >
>> > > > > > > >
>> > > > > > > > >
>> > > > > > > > > 6). And small remarks:
>> > > > > > > > > +jint vm_init1(JavaVM_Internal * java_vm,
>> JavaVMInitArgs * vm_arguments);
>> > > > > > > > > +jint vm_init2(JNIEnv_Internal * jni_env);
>> > > > > > > > > Could you make names more meaningful, then 1,2,3...?
>> > > > > > > > Ok, will do that.
>> > > > > > > >
>> > > > > > > > >
>> > > > > > > > > class VM_thread {
>> > > > > > > > > ...
>> > > > > > > > > + JNIEnv_Internal * jni_env;
>> > > > > > > > > The jthread already has the jni_env pointer, you do
>> not need to
>> > > > > > > > > duplicate it here.
>> > > > > > > > > forexample by using jthread_get_JNI_env(jthread_self());
>> > > > > > > >
>> > > > > > > > Yes I know. I don't see any problems here. Some times it
>> is much more
>> > > > > > > > convenient to get JNIEnv from VM_thread structure (and
>> faster) instead
>> > > > > > > > of doing jthread_get_JNI_env(jthread_self()). So I need
>> strong
>> > > > > > > > arguments for removing it. Again it seems that should be
>> addressed in
>> > > > > > > > design of multi VM. So lets forget about it for a while...
>> > > > > > >
>> > > > > > > I think that the data duplication would always serve as a
>> potential
>> > > > > > > source of errors - while updating one copy of object, you
>> may forget
>> > > > > > > to update the other, often resulting into a strange
>> behavior of the
>> > > > > > > whole application. Let's see what are the specific
>> performance
>> > > > > > > concerns that have to be addressed. To get VM_thread
>> structure, you
>> > > > > > > would eventually go to the TLS, just like
>> > > > > > > jthread_get_JNI_env(jthread_self() would do.
>> > > > > > If there is already VM_thread structure for some reasons
>> then there
>> > > > > > will be no extra access to TLS. It is definitely much more in
>> > > > > > jthread_get_JNI_env(jthread_self() than just one TLS access
>> and one
>> > > > > > dereferncing. I don't think it is a really big problem now.
>> Do you
>> > > > > > agree to look at this later. I guess multi VM implementation
>> will
>> > > > > > alter it in any case.
>> > > > > >
>> > > > > > Thanks
>> > > > > > Evgueni
>> > > > > >
>> > > > > > >
>> > > > > > > Thanks,
>> > > > > > > Andrey.
>> > > > > > >
>> > > > > > > >
>> > > > > > > > Evgueni
>> > > > > > > > >
>> > > > > > > > > Thanks
>> > > > > > > > > Artem
>> > > > > > > > >
>> > > > > > > > > On 9/28/06, Evgueni Brevnov
>> <ev...@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.
>> > > > > > > > > >
>> > > > > > > > > > Thanks
>> > > > > > > > > > Evgueni
>> > > > > > > > > >
>> > > > > > > > > > On 9/28/06, Geir Magnusson Jr. <ge...@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
>> <we...@gmail.com> wrote:
>> > > > > > > > > > > >> On 9/26/06, Evgueni Brevnov
>> <ev...@gmail.com> wrote:
>> > > > > > > > > > > >> >
>> > > > > > > > > > > >> > On 9/27/06, Andrey Chernyshev
>> <a....@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
>> > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > >
>> > > > > > > > >
>> ---------------------------------------------------------------------
>> > > > > > > > > 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
>> > > > > > > >
>> > > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > > --
>> > > > > > > Andrey Chernyshev
>> > > > > > > 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
>> > > > >
>> > > > >
>> > > >
>> > > >
>> > > > --
>> > > > Andrey Chernyshev
>> > > > 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
>> > >
>> > >
>> >
>> >
>> > --
>> > Andrey Chernyshev
>> > 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
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
Posted by Evgueni Brevnov <ev...@gmail.com>.
Hi All,
I have attached updated patch to the JIRA. It should resolve remain
concerns. Andrey, could you give a green light now?
Thanks
Evgueni
On 10/4/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> Andrey,
>
> I see your points. I think both approaches have advantages and
> disadvantages. I think it is quite hard to say which approach is
> better until we play with one VM only. I still feel like introducing
> one more dependence is better than spreading code which deals with
> attachment among VM and TM. We really get stuck. OK, just because I
> want to move forward I will do required changes to remove
> vm_create_jthread from TM. I believe that will resolve all our
> disagreements and the patch will be applied soon.
>
>
> Thanks
> Evgueni.
>
> On 10/4/06, Andrey Chernyshev <a....@gmail.com> wrote:
> > On 10/3/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> > > On 10/3/06, Andrey Chernyshev <a....@gmail.com> wrote:
> > > > On 10/2/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> > > > > Andrey,
> > > > >
> > > > > Just to be clear.... I agree with you it is more convenient if
> > > > > jthread_create takes JNIEnv instead of JavaVM. It reflects that
> > > > > current thread has been attached already. Do you think it makes sense
> > > > > to get rid of JNIEnv and use jthread_get_JNI_env in that case?
> > > >
> > > > The jthread_* layer is designed like if it were a regular JNI
> > > > application which is meant to be called from the Java code, hence
> > > > every function on that layer receives JNIenv. We can probably get rid
> > > > of the JNEnv parameter for jthread_* functions, assuming that TM can
> > > > always extract JNIenv for the current thread with
> > > > jthread_get_JNI_env().
> > > > My only concern would be the performance - once the JNIenv is already
> > > > known for the native part of the kernel classes impl, it must be
> > > > cheaper to pass JNIEnv to TM as an extra parameter rather than extract
> > > > it from the TLS again.
> > > > Other than that, I see no strong advantages in keeping JNIEnv parameter.
> > > >
> > > >
> > > > > Regarding jthread_attach. I still didn't get your point.... Clarify it
> > > > > please if you think jhread_attach should be modified.
> > > >
> > > > Sorry for being not clear: I think for jthread_attach, we have two options:
> > > > 1) Make JNIEnv input parameter - it must be new JNIEnv that VM
> > > > pre-allocates for the new Java thread. jthread_attach would just
> > > > associate it with the current thread.
> > > >
> > > > 2) Obtain JNIEnv via vm_attach() callback. In this case, if
> > > > vm_attach() callback implementation needs to know for which JavaVM new
> > > > JNIenv has to be allocated, then we'll need to add JavaVM as input
> > > > parameter for jthread_attach().
> > > > I think both options should be fine, (1) would probably keep TM
> > > > interface a bit lighter, though (2) may look more closer to the JNI
> > > > invocation API idea.
> > > > So I think adding JavaVM specifically for jthread_attach may make
> > > > sense given the explanation you provided earlier.
> > > >
> > > > The concern I would have regarding the proposed jthread_attach
> > > > implementation is a call to vm_create_jthread() - this call introduces
> > > > an extra dependency of TM on vmcore that I'd prefer to be avoided. In
> > > > the original version, jthread_attach() was taking jthread argument of
> > > > the already prepared j.l.Thread.
> > >
> > > I understand your concern. Unfortunately I don't see what we can do
> > > here. Let me explain. In the beginning you have an unattached native
> > > thread. To be able to call java code (which is required for
> > > constructing j.l.Thread instance) the thread should be attached first.
> > > To be specific it should be attached to VM by calling vm_attach which
> > > will return a valid JNIEnv It is valid to use JNI from that moment.
> > > Obtained JNIEnv can be used to execute java code and create j.l.Thread
> > > instance. Since we do vm_attach in jthread_attach we need to do
> > > vm_create_jthread inside jthread_atach as well.
> > > Of course it can be an alternative to do vm_attach and
> > > vm_create_jthread outside of TM right before jthread_attach. Sure it
> > > will reduce one dependence between VM and TM. But it seems like
> > > artificial action for me just because of dependency....
> >
> > Why do you think it is artificial? I would rather prefer not to throw
> > vm_attach event from the jthread_attach() call at all than to add
> > extra dependency. The idea of jthread layer is a Java face to
> > hythread, it is meant to know either a little or nothing about the
> > rest of VM. It may be logical to throw vm_attach call from the newly
> > created thread, because there is no other way to let know VM the new
> > thread is created. VM attach is a different case - VM already knows
> > about new Java thread at the time of the AttachCurrentThread call.
> >
> > >
> > > > Do you think it makes sense to replace a single jthread parameter with
> > > > a variety of stuff (like thread group, name)? It seems the only
> > > > purpose of at these args is to be passed back to VM for
> > > > vm_jthread_create(). I would suggest to change this and try doing
> > > > either of:
> > > > 1) Make signature of jthread_attach with 3 args, JavaVM, jthread and the daemon.
> > > Why do you want to pass daemon to TM but thread's name and group. Just
> > > because current TM doesn't need such information? What if it is
> > > required to get thread name later? Say by introducing
> >
> > I imagine you need a daemon attribute since the TM is still managing
> > the thread daemonality. TM is not managing thread name and group -
> > they are all kept on the Java level, hence passing them may be
> > excessive.
> >
> > > jthread_get_name... What will you do in that case? Let me guess you
> > > will call j.l.Thread.getName. Right. Ok! In that case I see no
> > > problems to call j.l.Thread.isDaemon. Do you agree? So it doesn't
> >
> > As I suggested earlier, the best way to handle daemonality would
> > probably be in pure Java - in j.l.Thread (or j.l.VMThreadManager) or
> > whatever. You already lifted it up to the jthread level, but what if
> > we can go a little bit higher...
> >
> > > seems to be a good design to pass only part of the information to
> > > jthread_atach. Lets look at the signature of AttachCurrentThread. It
> > > takes exactly these three parameters (daemon, name, group) passed as a
> > > structure. I was thinking about having exactly the same structure as
> > > third parameter of jthread_attach but it occured to be more convinient
> > > to pass them seperatly. Although I don't see strong reasons against
> > > having a structure a third parameter.
> >
> > I see. Acually, I would love to keep the jthread_attach func-ty at the
> > minimum level which will be needed to handle the only data that TM
> > should be aware of. We need a formal boundary between jthread layer
> > and vmcore (otherwise jthread won't have a much of sense, one may
> > consider it just as a convenience set of functions in vmcore which are
> > doing something with threading).
> >
> > >
> > > > 2) Move the implementation of vm_create_jtrhead() to
> > > > thread_java_basic.c - could it be written in pure JNI without using
> > > > internal VM API like class_alloc_new_object()?
> > >
> > > Yes, this can be done but it doesn't fix the problem. You still need
> > > to know about internal constructor of j.l.Thread
> >
> > That's bad. Given what you said, now it seems that the most preferable
> > sequence for AttachCurrentThread impl still would be like:
> > JNIEnv = vm_attach();
> > jthread = create_jthread(JNIenv)
> > jthread_attach(JNIEnv, jthread) // stores JNIEnv and Hythread into
> > TLS, doesn't call vm_attach any longer.
> > - this is almost what we had from the beginning...
> >
> > Thanks,
> > Andrey.
> >
> > >
> > >
> > > Thanks
> > > Evgueni
> > > >
> > > >
> > > > Thanks,
> > > > Andrey.
> > > >
> > > > >
> > > > > Thank you
> > > > > Evgueni
> > > > >
> > > > > On 10/2/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> > > > > > On 9/29/06, Andrey Chernyshev <a....@gmail.com> wrote:
> > > > > > > On 9/29/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> > > > > > > > Artem,
> > > > > > > >
> > > > > > > > Thank you for your feedback.... find my inlined.....
> > > > > > > >
> > > > > > > > On 9/29/06, Artem Aliev <ar...@gmail.com> wrote:
> > > > > > > > > Evgueni,
> > > > > > > > >
> > > > > > > > > I got most of your changes, but still disagree with all
> > > > > > > > > hythread/jthread interface changes. Could leave interface unchanged.
> > > > > > > > > See following possible solutions, that could solve the same problems
> > > > > > > > > without interface changes.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > 1) daemon attribute is a java specific. (Andrey mentioned this already).
> > > > > > > > > Could you please move it back. to the jthread layer. It is better
> > > > > > > > > to rename
> > > > > > > > > hythread_wait_for_all_nondaemon_threads() to
> > > > > > > > > jthread_wait_for_all_nondaemon_threads().
> > > > > > > > Ok, I see no problems to move "daemon" to java layer. In that case:
> > > > > > > > 1) I will move hythread_wait_for_all_nondaemon_threads() from
> > > > > > > > thread_init.c to one which implements java layer.
> > > > > > > > 2) I will move daemon field from HyThread structure.
> > > > > > > >
> > > > > > > > Agree?
> > > > > > >
> > > > > > > Sounds good to me.
> > > > > >
> > > > > > OK, will do that.
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > > 2) JavaVM could be retrieved from JNIEnv by jni_get_java_vm(). So
> > > > > > > > > let the jthread_create() and others to use JNIEnv (that is passed from
> > > > > > > > > java native method).
> > > > > > > > > The vm_attach could get old JNI env and create new one for the new thread.
> > > > > > > > > The first JNIEnv is created in CreateVM call and could be passed to
> > > > > > > > > the first thread at startup.
> > > > > > > > No, no, no. I completely disagree with that!!! Why do you like JNIEnv
> > > > > > > > but JavaVM. Why do you think that passing JavaVM instead of JNIEnv
> > > > > > > > makes TM less modular? I don't see any difference here.... It seems
> > > > > > > > for me like a big big hack to grab JNIEnv from another thread and pass
> > > > > > > > it to jthread_attach to perform operations in the current thread.
> > > > > > >
> > > > > > > TM needs to know JNIEnv, mainly for managing the references to
> > > > > > > objects, throwing exceptions and calling run() method of a new thread.
> > > > > > > JNI spec proposes that JNIEnv is valid within the given thread, this
> > > > > > > is why TM holds the JNIEnv pointer at the moment. This is why TM likes
> > > > > > > the JNIEnv.
> > > > > > >
> > > > > > > Having the JNIEnv, one is able to get JavaVM but not vise versa. This
> > > > > > > is why TM doesn't like the JavaVM :)
> > > > > > I see your point. Only one note this is true for already attached threads...
> > > > > >
> > > > > > >
> > > > > > > I agree with you that there is a design flaw that the JNIEnv is copied
> > > > > > > from the parent thread to a child thread during thread creation. I
> > > > > > > think it could be resolved via vm_attach() hook - with this event, VM
> > > > > > > might tell the TM what the JNIEnv pointer for new thread should be. I
> > > > > > > think you did that by extending the vm_attach() call with the JNIEnv**
> > > > > > > argument.
> > > > > > >
> > > > > > > What is not completely clear is, why do you have to pass the JavaVM
> > > > > > > forth and back, once from VM to TM, and then back from TM to VM again?
> > > > > > >
> > > > > > > If you need to know in jthread_attach, which particular VM vm_attach()
> > > > > > > event is coming from, you could have vm_attach like
> > > > > > > vm_attach(JNIEnv* currentThreadEnv, JNIEnv** newThreadEnv).
> > > > > > I'm a little bit confused.....Current thread hasn't been attached yet.
> > > > > > So there is no JNIEnv for it yet. How it can be passed as the first
> > > > > > parameter to vm_attach()?
> > > > > >
> > > > > > > Then you will be always able to get the JavaVM from the JNIEnv.
> > > > > > > The only difference is that you are currently doing JNIEnv->JavaVM
> > > > > > > conversion in the VMThreadManager, but why can't you just do this in
> > > > > > > vm_attach() without changing the interface of the TM?
> > > > > > > So far JavaVM really looks like an extra knowledge that TM doesn't
> > > > > > > have to be aware of.
> > > > > > >
> > > > > > > > Moreover there is no JNIEnv when main thread attaches to VM. So we
> > > > > > > > should either keep it as is or change original design of TM and attach
> > > > > > > > thread to VM before attaching it to TM. In that case we will have
> > > > > > > > valid JNIEnv which can be passed to jthread_atatch. We need to think
> > > > > > > > over it twice before changing something....
> > > > > > >
> > > > > > > Right. For jthread_attach, JNIenv needs to be changed from being input
> > > > > > > parameter to being the output parameter. The way how JNIenv is
> > > > > > > obtained by TM should be vm_attach() event.
> > > > > > OK, JNIEnv is output parameter. And it obtained by vm_attach(). This
> > > > > > is exactly like I do in the patch. What I don't understand is how
> > > > > > jthread_attach knows to which VM the thread should be attached? Do you
> > > > > > suggest calling vm_attach first to create JNIEnv it pass it to
> > > > > > jthread_attach?
> > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > 4) Original classlib hythread do not use hythread_library_t in arguments,
> > > > > > > > > It uses following code:
> > > > > > > > >
> > > > > > > > > hythread_library_t lib = GLOBAL_DATA (default_library);
> > > > > > > > > or
> > > > > > > > > hythread_library_t library = thread->library;
> > > > > > > > >
> > > > > > > > > So could you please use the same mechanism and remove hythread_*_ex >functions.
> > > > > > > > Let's see if classlib's hythread needs changing first. It seems for me
> > > > > > > > such code prevents us from having multi VM.
> > > > > > > >
> > > > > > > > >
> > > > > > > > > 5. You introduce more then one jni env, but still use global variable for it.
> > > > > > > > > So all changes like following:
> > > > > > > > > - JNIEnv *jenv = (JNIEnv*)jni_native_intf;
> > > > > > > > > + JNIEnv *jenv = jni_native_intf;
> > > > > > > > >
> > > > > > > > > should be like:
> > > > > > > > > - JNIEnv *jenv = (JNIEnv*)jni_native_intf;
> > > > > > > > > + JNIEnv *jenv = get_jni_env(jthread_self());
> > > > > > > >
> > > > > > > > Ok, I see. I agree that global jni_native_intf should not be used.
> > > > > > > > There was simple reason why I altered such lines. Because I changed
> > > > > > > > the type of jni_native_intf and no casting operator is needed now. To
> > > > > > > > be honest I think get_jni_env(jthread_self()) can be good as temporary
> > > > > > > > solution only. Lets wait for design of multi VM and fix it according
> > > > > > > > to it.
> > > > > > >
> > > > > > > While we are in JNI code, we always have the JNIenv (at least
> > > > > > > initially it comes from Java code). If we consider VM code as if it
> > > > > > > was a JNI application, then it seems like we should be just passing
> > > > > > > JNIEnv as a parameter to all functions in VM. Or, we can be taking it
> > > > > > > from TLS (via jthread_self()), depending on which way is faster...
> > > > > > Agree.
> > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > > 6). And small remarks:
> > > > > > > > > +jint vm_init1(JavaVM_Internal * java_vm, JavaVMInitArgs * vm_arguments);
> > > > > > > > > +jint vm_init2(JNIEnv_Internal * jni_env);
> > > > > > > > > Could you make names more meaningful, then 1,2,3...?
> > > > > > > > Ok, will do that.
> > > > > > > >
> > > > > > > > >
> > > > > > > > > class VM_thread {
> > > > > > > > > ...
> > > > > > > > > + JNIEnv_Internal * jni_env;
> > > > > > > > > The jthread already has the jni_env pointer, you do not need to
> > > > > > > > > duplicate it here.
> > > > > > > > > forexample by using jthread_get_JNI_env(jthread_self());
> > > > > > > >
> > > > > > > > Yes I know. I don't see any problems here. Some times it is much more
> > > > > > > > convenient to get JNIEnv from VM_thread structure (and faster) instead
> > > > > > > > of doing jthread_get_JNI_env(jthread_self()). So I need strong
> > > > > > > > arguments for removing it. Again it seems that should be addressed in
> > > > > > > > design of multi VM. So lets forget about it for a while...
> > > > > > >
> > > > > > > I think that the data duplication would always serve as a potential
> > > > > > > source of errors - while updating one copy of object, you may forget
> > > > > > > to update the other, often resulting into a strange behavior of the
> > > > > > > whole application. Let's see what are the specific performance
> > > > > > > concerns that have to be addressed. To get VM_thread structure, you
> > > > > > > would eventually go to the TLS, just like
> > > > > > > jthread_get_JNI_env(jthread_self() would do.
> > > > > > If there is already VM_thread structure for some reasons then there
> > > > > > will be no extra access to TLS. It is definitely much more in
> > > > > > jthread_get_JNI_env(jthread_self() than just one TLS access and one
> > > > > > dereferncing. I don't think it is a really big problem now. Do you
> > > > > > agree to look at this later. I guess multi VM implementation will
> > > > > > alter it in any case.
> > > > > >
> > > > > > Thanks
> > > > > > Evgueni
> > > > > >
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Andrey.
> > > > > > >
> > > > > > > >
> > > > > > > > Evgueni
> > > > > > > > >
> > > > > > > > > Thanks
> > > > > > > > > Artem
> > > > > > > > >
> > > > > > > > > On 9/28/06, Evgueni Brevnov <ev...@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.
> > > > > > > > > >
> > > > > > > > > > Thanks
> > > > > > > > > > Evgueni
> > > > > > > > > >
> > > > > > > > > > On 9/28/06, Geir Magnusson Jr. <ge...@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 <we...@gmail.com> wrote:
> > > > > > > > > > > >> On 9/26/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> > > > > > > > > > > >> >
> > > > > > > > > > > >> > On 9/27/06, Andrey Chernyshev <a....@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
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > ---------------------------------------------------------------------
> > > > > > > > > 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
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Andrey Chernyshev
> > > > > > > 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
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Andrey Chernyshev
> > > > 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
> > >
> > >
> >
> >
> > --
> > Andrey Chernyshev
> > 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
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
Posted by Evgueni Brevnov <ev...@gmail.com>.
Andrey,
I see your points. I think both approaches have advantages and
disadvantages. I think it is quite hard to say which approach is
better until we play with one VM only. I still feel like introducing
one more dependence is better than spreading code which deals with
attachment among VM and TM. We really get stuck. OK, just because I
want to move forward I will do required changes to remove
vm_create_jthread from TM. I believe that will resolve all our
disagreements and the patch will be applied soon.
Thanks
Evgueni.
On 10/4/06, Andrey Chernyshev <a....@gmail.com> wrote:
> On 10/3/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> > On 10/3/06, Andrey Chernyshev <a....@gmail.com> wrote:
> > > On 10/2/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> > > > Andrey,
> > > >
> > > > Just to be clear.... I agree with you it is more convenient if
> > > > jthread_create takes JNIEnv instead of JavaVM. It reflects that
> > > > current thread has been attached already. Do you think it makes sense
> > > > to get rid of JNIEnv and use jthread_get_JNI_env in that case?
> > >
> > > The jthread_* layer is designed like if it were a regular JNI
> > > application which is meant to be called from the Java code, hence
> > > every function on that layer receives JNIenv. We can probably get rid
> > > of the JNEnv parameter for jthread_* functions, assuming that TM can
> > > always extract JNIenv for the current thread with
> > > jthread_get_JNI_env().
> > > My only concern would be the performance - once the JNIenv is already
> > > known for the native part of the kernel classes impl, it must be
> > > cheaper to pass JNIEnv to TM as an extra parameter rather than extract
> > > it from the TLS again.
> > > Other than that, I see no strong advantages in keeping JNIEnv parameter.
> > >
> > >
> > > > Regarding jthread_attach. I still didn't get your point.... Clarify it
> > > > please if you think jhread_attach should be modified.
> > >
> > > Sorry for being not clear: I think for jthread_attach, we have two options:
> > > 1) Make JNIEnv input parameter - it must be new JNIEnv that VM
> > > pre-allocates for the new Java thread. jthread_attach would just
> > > associate it with the current thread.
> > >
> > > 2) Obtain JNIEnv via vm_attach() callback. In this case, if
> > > vm_attach() callback implementation needs to know for which JavaVM new
> > > JNIenv has to be allocated, then we'll need to add JavaVM as input
> > > parameter for jthread_attach().
> > > I think both options should be fine, (1) would probably keep TM
> > > interface a bit lighter, though (2) may look more closer to the JNI
> > > invocation API idea.
> > > So I think adding JavaVM specifically for jthread_attach may make
> > > sense given the explanation you provided earlier.
> > >
> > > The concern I would have regarding the proposed jthread_attach
> > > implementation is a call to vm_create_jthread() - this call introduces
> > > an extra dependency of TM on vmcore that I'd prefer to be avoided. In
> > > the original version, jthread_attach() was taking jthread argument of
> > > the already prepared j.l.Thread.
> >
> > I understand your concern. Unfortunately I don't see what we can do
> > here. Let me explain. In the beginning you have an unattached native
> > thread. To be able to call java code (which is required for
> > constructing j.l.Thread instance) the thread should be attached first.
> > To be specific it should be attached to VM by calling vm_attach which
> > will return a valid JNIEnv It is valid to use JNI from that moment.
> > Obtained JNIEnv can be used to execute java code and create j.l.Thread
> > instance. Since we do vm_attach in jthread_attach we need to do
> > vm_create_jthread inside jthread_atach as well.
> > Of course it can be an alternative to do vm_attach and
> > vm_create_jthread outside of TM right before jthread_attach. Sure it
> > will reduce one dependence between VM and TM. But it seems like
> > artificial action for me just because of dependency....
>
> Why do you think it is artificial? I would rather prefer not to throw
> vm_attach event from the jthread_attach() call at all than to add
> extra dependency. The idea of jthread layer is a Java face to
> hythread, it is meant to know either a little or nothing about the
> rest of VM. It may be logical to throw vm_attach call from the newly
> created thread, because there is no other way to let know VM the new
> thread is created. VM attach is a different case - VM already knows
> about new Java thread at the time of the AttachCurrentThread call.
>
> >
> > > Do you think it makes sense to replace a single jthread parameter with
> > > a variety of stuff (like thread group, name)? It seems the only
> > > purpose of at these args is to be passed back to VM for
> > > vm_jthread_create(). I would suggest to change this and try doing
> > > either of:
> > > 1) Make signature of jthread_attach with 3 args, JavaVM, jthread and the daemon.
> > Why do you want to pass daemon to TM but thread's name and group. Just
> > because current TM doesn't need such information? What if it is
> > required to get thread name later? Say by introducing
>
> I imagine you need a daemon attribute since the TM is still managing
> the thread daemonality. TM is not managing thread name and group -
> they are all kept on the Java level, hence passing them may be
> excessive.
>
> > jthread_get_name... What will you do in that case? Let me guess you
> > will call j.l.Thread.getName. Right. Ok! In that case I see no
> > problems to call j.l.Thread.isDaemon. Do you agree? So it doesn't
>
> As I suggested earlier, the best way to handle daemonality would
> probably be in pure Java - in j.l.Thread (or j.l.VMThreadManager) or
> whatever. You already lifted it up to the jthread level, but what if
> we can go a little bit higher...
>
> > seems to be a good design to pass only part of the information to
> > jthread_atach. Lets look at the signature of AttachCurrentThread. It
> > takes exactly these three parameters (daemon, name, group) passed as a
> > structure. I was thinking about having exactly the same structure as
> > third parameter of jthread_attach but it occured to be more convinient
> > to pass them seperatly. Although I don't see strong reasons against
> > having a structure a third parameter.
>
> I see. Acually, I would love to keep the jthread_attach func-ty at the
> minimum level which will be needed to handle the only data that TM
> should be aware of. We need a formal boundary between jthread layer
> and vmcore (otherwise jthread won't have a much of sense, one may
> consider it just as a convenience set of functions in vmcore which are
> doing something with threading).
>
> >
> > > 2) Move the implementation of vm_create_jtrhead() to
> > > thread_java_basic.c - could it be written in pure JNI without using
> > > internal VM API like class_alloc_new_object()?
> >
> > Yes, this can be done but it doesn't fix the problem. You still need
> > to know about internal constructor of j.l.Thread
>
> That's bad. Given what you said, now it seems that the most preferable
> sequence for AttachCurrentThread impl still would be like:
> JNIEnv = vm_attach();
> jthread = create_jthread(JNIenv)
> jthread_attach(JNIEnv, jthread) // stores JNIEnv and Hythread into
> TLS, doesn't call vm_attach any longer.
> - this is almost what we had from the beginning...
>
> Thanks,
> Andrey.
>
> >
> >
> > Thanks
> > Evgueni
> > >
> > >
> > > Thanks,
> > > Andrey.
> > >
> > > >
> > > > Thank you
> > > > Evgueni
> > > >
> > > > On 10/2/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> > > > > On 9/29/06, Andrey Chernyshev <a....@gmail.com> wrote:
> > > > > > On 9/29/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> > > > > > > Artem,
> > > > > > >
> > > > > > > Thank you for your feedback.... find my inlined.....
> > > > > > >
> > > > > > > On 9/29/06, Artem Aliev <ar...@gmail.com> wrote:
> > > > > > > > Evgueni,
> > > > > > > >
> > > > > > > > I got most of your changes, but still disagree with all
> > > > > > > > hythread/jthread interface changes. Could leave interface unchanged.
> > > > > > > > See following possible solutions, that could solve the same problems
> > > > > > > > without interface changes.
> > > > > > > >
> > > > > > > >
> > > > > > > > 1) daemon attribute is a java specific. (Andrey mentioned this already).
> > > > > > > > Could you please move it back. to the jthread layer. It is better
> > > > > > > > to rename
> > > > > > > > hythread_wait_for_all_nondaemon_threads() to
> > > > > > > > jthread_wait_for_all_nondaemon_threads().
> > > > > > > Ok, I see no problems to move "daemon" to java layer. In that case:
> > > > > > > 1) I will move hythread_wait_for_all_nondaemon_threads() from
> > > > > > > thread_init.c to one which implements java layer.
> > > > > > > 2) I will move daemon field from HyThread structure.
> > > > > > >
> > > > > > > Agree?
> > > > > >
> > > > > > Sounds good to me.
> > > > >
> > > > > OK, will do that.
> > > > >
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > 2) JavaVM could be retrieved from JNIEnv by jni_get_java_vm(). So
> > > > > > > > let the jthread_create() and others to use JNIEnv (that is passed from
> > > > > > > > java native method).
> > > > > > > > The vm_attach could get old JNI env and create new one for the new thread.
> > > > > > > > The first JNIEnv is created in CreateVM call and could be passed to
> > > > > > > > the first thread at startup.
> > > > > > > No, no, no. I completely disagree with that!!! Why do you like JNIEnv
> > > > > > > but JavaVM. Why do you think that passing JavaVM instead of JNIEnv
> > > > > > > makes TM less modular? I don't see any difference here.... It seems
> > > > > > > for me like a big big hack to grab JNIEnv from another thread and pass
> > > > > > > it to jthread_attach to perform operations in the current thread.
> > > > > >
> > > > > > TM needs to know JNIEnv, mainly for managing the references to
> > > > > > objects, throwing exceptions and calling run() method of a new thread.
> > > > > > JNI spec proposes that JNIEnv is valid within the given thread, this
> > > > > > is why TM holds the JNIEnv pointer at the moment. This is why TM likes
> > > > > > the JNIEnv.
> > > > > >
> > > > > > Having the JNIEnv, one is able to get JavaVM but not vise versa. This
> > > > > > is why TM doesn't like the JavaVM :)
> > > > > I see your point. Only one note this is true for already attached threads...
> > > > >
> > > > > >
> > > > > > I agree with you that there is a design flaw that the JNIEnv is copied
> > > > > > from the parent thread to a child thread during thread creation. I
> > > > > > think it could be resolved via vm_attach() hook - with this event, VM
> > > > > > might tell the TM what the JNIEnv pointer for new thread should be. I
> > > > > > think you did that by extending the vm_attach() call with the JNIEnv**
> > > > > > argument.
> > > > > >
> > > > > > What is not completely clear is, why do you have to pass the JavaVM
> > > > > > forth and back, once from VM to TM, and then back from TM to VM again?
> > > > > >
> > > > > > If you need to know in jthread_attach, which particular VM vm_attach()
> > > > > > event is coming from, you could have vm_attach like
> > > > > > vm_attach(JNIEnv* currentThreadEnv, JNIEnv** newThreadEnv).
> > > > > I'm a little bit confused.....Current thread hasn't been attached yet.
> > > > > So there is no JNIEnv for it yet. How it can be passed as the first
> > > > > parameter to vm_attach()?
> > > > >
> > > > > > Then you will be always able to get the JavaVM from the JNIEnv.
> > > > > > The only difference is that you are currently doing JNIEnv->JavaVM
> > > > > > conversion in the VMThreadManager, but why can't you just do this in
> > > > > > vm_attach() without changing the interface of the TM?
> > > > > > So far JavaVM really looks like an extra knowledge that TM doesn't
> > > > > > have to be aware of.
> > > > > >
> > > > > > > Moreover there is no JNIEnv when main thread attaches to VM. So we
> > > > > > > should either keep it as is or change original design of TM and attach
> > > > > > > thread to VM before attaching it to TM. In that case we will have
> > > > > > > valid JNIEnv which can be passed to jthread_atatch. We need to think
> > > > > > > over it twice before changing something....
> > > > > >
> > > > > > Right. For jthread_attach, JNIenv needs to be changed from being input
> > > > > > parameter to being the output parameter. The way how JNIenv is
> > > > > > obtained by TM should be vm_attach() event.
> > > > > OK, JNIEnv is output parameter. And it obtained by vm_attach(). This
> > > > > is exactly like I do in the patch. What I don't understand is how
> > > > > jthread_attach knows to which VM the thread should be attached? Do you
> > > > > suggest calling vm_attach first to create JNIEnv it pass it to
> > > > > jthread_attach?
> > > > >
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > 4) Original classlib hythread do not use hythread_library_t in arguments,
> > > > > > > > It uses following code:
> > > > > > > >
> > > > > > > > hythread_library_t lib = GLOBAL_DATA (default_library);
> > > > > > > > or
> > > > > > > > hythread_library_t library = thread->library;
> > > > > > > >
> > > > > > > > So could you please use the same mechanism and remove hythread_*_ex >functions.
> > > > > > > Let's see if classlib's hythread needs changing first. It seems for me
> > > > > > > such code prevents us from having multi VM.
> > > > > > >
> > > > > > > >
> > > > > > > > 5. You introduce more then one jni env, but still use global variable for it.
> > > > > > > > So all changes like following:
> > > > > > > > - JNIEnv *jenv = (JNIEnv*)jni_native_intf;
> > > > > > > > + JNIEnv *jenv = jni_native_intf;
> > > > > > > >
> > > > > > > > should be like:
> > > > > > > > - JNIEnv *jenv = (JNIEnv*)jni_native_intf;
> > > > > > > > + JNIEnv *jenv = get_jni_env(jthread_self());
> > > > > > >
> > > > > > > Ok, I see. I agree that global jni_native_intf should not be used.
> > > > > > > There was simple reason why I altered such lines. Because I changed
> > > > > > > the type of jni_native_intf and no casting operator is needed now. To
> > > > > > > be honest I think get_jni_env(jthread_self()) can be good as temporary
> > > > > > > solution only. Lets wait for design of multi VM and fix it according
> > > > > > > to it.
> > > > > >
> > > > > > While we are in JNI code, we always have the JNIenv (at least
> > > > > > initially it comes from Java code). If we consider VM code as if it
> > > > > > was a JNI application, then it seems like we should be just passing
> > > > > > JNIEnv as a parameter to all functions in VM. Or, we can be taking it
> > > > > > from TLS (via jthread_self()), depending on which way is faster...
> > > > > Agree.
> > > > >
> > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > 6). And small remarks:
> > > > > > > > +jint vm_init1(JavaVM_Internal * java_vm, JavaVMInitArgs * vm_arguments);
> > > > > > > > +jint vm_init2(JNIEnv_Internal * jni_env);
> > > > > > > > Could you make names more meaningful, then 1,2,3...?
> > > > > > > Ok, will do that.
> > > > > > >
> > > > > > > >
> > > > > > > > class VM_thread {
> > > > > > > > ...
> > > > > > > > + JNIEnv_Internal * jni_env;
> > > > > > > > The jthread already has the jni_env pointer, you do not need to
> > > > > > > > duplicate it here.
> > > > > > > > forexample by using jthread_get_JNI_env(jthread_self());
> > > > > > >
> > > > > > > Yes I know. I don't see any problems here. Some times it is much more
> > > > > > > convenient to get JNIEnv from VM_thread structure (and faster) instead
> > > > > > > of doing jthread_get_JNI_env(jthread_self()). So I need strong
> > > > > > > arguments for removing it. Again it seems that should be addressed in
> > > > > > > design of multi VM. So lets forget about it for a while...
> > > > > >
> > > > > > I think that the data duplication would always serve as a potential
> > > > > > source of errors - while updating one copy of object, you may forget
> > > > > > to update the other, often resulting into a strange behavior of the
> > > > > > whole application. Let's see what are the specific performance
> > > > > > concerns that have to be addressed. To get VM_thread structure, you
> > > > > > would eventually go to the TLS, just like
> > > > > > jthread_get_JNI_env(jthread_self() would do.
> > > > > If there is already VM_thread structure for some reasons then there
> > > > > will be no extra access to TLS. It is definitely much more in
> > > > > jthread_get_JNI_env(jthread_self() than just one TLS access and one
> > > > > dereferncing. I don't think it is a really big problem now. Do you
> > > > > agree to look at this later. I guess multi VM implementation will
> > > > > alter it in any case.
> > > > >
> > > > > Thanks
> > > > > Evgueni
> > > > >
> > > > > >
> > > > > > Thanks,
> > > > > > Andrey.
> > > > > >
> > > > > > >
> > > > > > > Evgueni
> > > > > > > >
> > > > > > > > Thanks
> > > > > > > > Artem
> > > > > > > >
> > > > > > > > On 9/28/06, Evgueni Brevnov <ev...@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.
> > > > > > > > >
> > > > > > > > > Thanks
> > > > > > > > > Evgueni
> > > > > > > > >
> > > > > > > > > On 9/28/06, Geir Magnusson Jr. <ge...@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 <we...@gmail.com> wrote:
> > > > > > > > > > >> On 9/26/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> > > > > > > > > > >> >
> > > > > > > > > > >> > On 9/27/06, Andrey Chernyshev <a....@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
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > ---------------------------------------------------------------------
> > > > > > > > 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
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Andrey Chernyshev
> > > > > > 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
> > > >
> > > >
> > >
> > >
> > > --
> > > Andrey Chernyshev
> > > 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
> >
> >
>
>
> --
> Andrey Chernyshev
> 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
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
Posted by Andrey Chernyshev <a....@gmail.com>.
On 10/3/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> On 10/3/06, Andrey Chernyshev <a....@gmail.com> wrote:
> > On 10/2/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> > > Andrey,
> > >
> > > Just to be clear.... I agree with you it is more convenient if
> > > jthread_create takes JNIEnv instead of JavaVM. It reflects that
> > > current thread has been attached already. Do you think it makes sense
> > > to get rid of JNIEnv and use jthread_get_JNI_env in that case?
> >
> > The jthread_* layer is designed like if it were a regular JNI
> > application which is meant to be called from the Java code, hence
> > every function on that layer receives JNIenv. We can probably get rid
> > of the JNEnv parameter for jthread_* functions, assuming that TM can
> > always extract JNIenv for the current thread with
> > jthread_get_JNI_env().
> > My only concern would be the performance - once the JNIenv is already
> > known for the native part of the kernel classes impl, it must be
> > cheaper to pass JNIEnv to TM as an extra parameter rather than extract
> > it from the TLS again.
> > Other than that, I see no strong advantages in keeping JNIEnv parameter.
> >
> >
> > > Regarding jthread_attach. I still didn't get your point.... Clarify it
> > > please if you think jhread_attach should be modified.
> >
> > Sorry for being not clear: I think for jthread_attach, we have two options:
> > 1) Make JNIEnv input parameter - it must be new JNIEnv that VM
> > pre-allocates for the new Java thread. jthread_attach would just
> > associate it with the current thread.
> >
> > 2) Obtain JNIEnv via vm_attach() callback. In this case, if
> > vm_attach() callback implementation needs to know for which JavaVM new
> > JNIenv has to be allocated, then we'll need to add JavaVM as input
> > parameter for jthread_attach().
> > I think both options should be fine, (1) would probably keep TM
> > interface a bit lighter, though (2) may look more closer to the JNI
> > invocation API idea.
> > So I think adding JavaVM specifically for jthread_attach may make
> > sense given the explanation you provided earlier.
> >
> > The concern I would have regarding the proposed jthread_attach
> > implementation is a call to vm_create_jthread() - this call introduces
> > an extra dependency of TM on vmcore that I'd prefer to be avoided. In
> > the original version, jthread_attach() was taking jthread argument of
> > the already prepared j.l.Thread.
>
> I understand your concern. Unfortunately I don't see what we can do
> here. Let me explain. In the beginning you have an unattached native
> thread. To be able to call java code (which is required for
> constructing j.l.Thread instance) the thread should be attached first.
> To be specific it should be attached to VM by calling vm_attach which
> will return a valid JNIEnv It is valid to use JNI from that moment.
> Obtained JNIEnv can be used to execute java code and create j.l.Thread
> instance. Since we do vm_attach in jthread_attach we need to do
> vm_create_jthread inside jthread_atach as well.
> Of course it can be an alternative to do vm_attach and
> vm_create_jthread outside of TM right before jthread_attach. Sure it
> will reduce one dependence between VM and TM. But it seems like
> artificial action for me just because of dependency....
Why do you think it is artificial? I would rather prefer not to throw
vm_attach event from the jthread_attach() call at all than to add
extra dependency. The idea of jthread layer is a Java face to
hythread, it is meant to know either a little or nothing about the
rest of VM. It may be logical to throw vm_attach call from the newly
created thread, because there is no other way to let know VM the new
thread is created. VM attach is a different case - VM already knows
about new Java thread at the time of the AttachCurrentThread call.
>
> > Do you think it makes sense to replace a single jthread parameter with
> > a variety of stuff (like thread group, name)? It seems the only
> > purpose of at these args is to be passed back to VM for
> > vm_jthread_create(). I would suggest to change this and try doing
> > either of:
> > 1) Make signature of jthread_attach with 3 args, JavaVM, jthread and the daemon.
> Why do you want to pass daemon to TM but thread's name and group. Just
> because current TM doesn't need such information? What if it is
> required to get thread name later? Say by introducing
I imagine you need a daemon attribute since the TM is still managing
the thread daemonality. TM is not managing thread name and group -
they are all kept on the Java level, hence passing them may be
excessive.
> jthread_get_name... What will you do in that case? Let me guess you
> will call j.l.Thread.getName. Right. Ok! In that case I see no
> problems to call j.l.Thread.isDaemon. Do you agree? So it doesn't
As I suggested earlier, the best way to handle daemonality would
probably be in pure Java - in j.l.Thread (or j.l.VMThreadManager) or
whatever. You already lifted it up to the jthread level, but what if
we can go a little bit higher...
> seems to be a good design to pass only part of the information to
> jthread_atach. Lets look at the signature of AttachCurrentThread. It
> takes exactly these three parameters (daemon, name, group) passed as a
> structure. I was thinking about having exactly the same structure as
> third parameter of jthread_attach but it occured to be more convinient
> to pass them seperatly. Although I don't see strong reasons against
> having a structure a third parameter.
I see. Acually, I would love to keep the jthread_attach func-ty at the
minimum level which will be needed to handle the only data that TM
should be aware of. We need a formal boundary between jthread layer
and vmcore (otherwise jthread won't have a much of sense, one may
consider it just as a convenience set of functions in vmcore which are
doing something with threading).
>
> > 2) Move the implementation of vm_create_jtrhead() to
> > thread_java_basic.c - could it be written in pure JNI without using
> > internal VM API like class_alloc_new_object()?
>
> Yes, this can be done but it doesn't fix the problem. You still need
> to know about internal constructor of j.l.Thread
That's bad. Given what you said, now it seems that the most preferable
sequence for AttachCurrentThread impl still would be like:
JNIEnv = vm_attach();
jthread = create_jthread(JNIenv)
jthread_attach(JNIEnv, jthread) // stores JNIEnv and Hythread into
TLS, doesn't call vm_attach any longer.
- this is almost what we had from the beginning...
Thanks,
Andrey.
>
>
> Thanks
> Evgueni
> >
> >
> > Thanks,
> > Andrey.
> >
> > >
> > > Thank you
> > > Evgueni
> > >
> > > On 10/2/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> > > > On 9/29/06, Andrey Chernyshev <a....@gmail.com> wrote:
> > > > > On 9/29/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> > > > > > Artem,
> > > > > >
> > > > > > Thank you for your feedback.... find my inlined.....
> > > > > >
> > > > > > On 9/29/06, Artem Aliev <ar...@gmail.com> wrote:
> > > > > > > Evgueni,
> > > > > > >
> > > > > > > I got most of your changes, but still disagree with all
> > > > > > > hythread/jthread interface changes. Could leave interface unchanged.
> > > > > > > See following possible solutions, that could solve the same problems
> > > > > > > without interface changes.
> > > > > > >
> > > > > > >
> > > > > > > 1) daemon attribute is a java specific. (Andrey mentioned this already).
> > > > > > > Could you please move it back. to the jthread layer. It is better
> > > > > > > to rename
> > > > > > > hythread_wait_for_all_nondaemon_threads() to
> > > > > > > jthread_wait_for_all_nondaemon_threads().
> > > > > > Ok, I see no problems to move "daemon" to java layer. In that case:
> > > > > > 1) I will move hythread_wait_for_all_nondaemon_threads() from
> > > > > > thread_init.c to one which implements java layer.
> > > > > > 2) I will move daemon field from HyThread structure.
> > > > > >
> > > > > > Agree?
> > > > >
> > > > > Sounds good to me.
> > > >
> > > > OK, will do that.
> > > >
> > > > >
> > > > >
> > > > > >
> > > > > > >
> > > > > > > 2) JavaVM could be retrieved from JNIEnv by jni_get_java_vm(). So
> > > > > > > let the jthread_create() and others to use JNIEnv (that is passed from
> > > > > > > java native method).
> > > > > > > The vm_attach could get old JNI env and create new one for the new thread.
> > > > > > > The first JNIEnv is created in CreateVM call and could be passed to
> > > > > > > the first thread at startup.
> > > > > > No, no, no. I completely disagree with that!!! Why do you like JNIEnv
> > > > > > but JavaVM. Why do you think that passing JavaVM instead of JNIEnv
> > > > > > makes TM less modular? I don't see any difference here.... It seems
> > > > > > for me like a big big hack to grab JNIEnv from another thread and pass
> > > > > > it to jthread_attach to perform operations in the current thread.
> > > > >
> > > > > TM needs to know JNIEnv, mainly for managing the references to
> > > > > objects, throwing exceptions and calling run() method of a new thread.
> > > > > JNI spec proposes that JNIEnv is valid within the given thread, this
> > > > > is why TM holds the JNIEnv pointer at the moment. This is why TM likes
> > > > > the JNIEnv.
> > > > >
> > > > > Having the JNIEnv, one is able to get JavaVM but not vise versa. This
> > > > > is why TM doesn't like the JavaVM :)
> > > > I see your point. Only one note this is true for already attached threads...
> > > >
> > > > >
> > > > > I agree with you that there is a design flaw that the JNIEnv is copied
> > > > > from the parent thread to a child thread during thread creation. I
> > > > > think it could be resolved via vm_attach() hook - with this event, VM
> > > > > might tell the TM what the JNIEnv pointer for new thread should be. I
> > > > > think you did that by extending the vm_attach() call with the JNIEnv**
> > > > > argument.
> > > > >
> > > > > What is not completely clear is, why do you have to pass the JavaVM
> > > > > forth and back, once from VM to TM, and then back from TM to VM again?
> > > > >
> > > > > If you need to know in jthread_attach, which particular VM vm_attach()
> > > > > event is coming from, you could have vm_attach like
> > > > > vm_attach(JNIEnv* currentThreadEnv, JNIEnv** newThreadEnv).
> > > > I'm a little bit confused.....Current thread hasn't been attached yet.
> > > > So there is no JNIEnv for it yet. How it can be passed as the first
> > > > parameter to vm_attach()?
> > > >
> > > > > Then you will be always able to get the JavaVM from the JNIEnv.
> > > > > The only difference is that you are currently doing JNIEnv->JavaVM
> > > > > conversion in the VMThreadManager, but why can't you just do this in
> > > > > vm_attach() without changing the interface of the TM?
> > > > > So far JavaVM really looks like an extra knowledge that TM doesn't
> > > > > have to be aware of.
> > > > >
> > > > > > Moreover there is no JNIEnv when main thread attaches to VM. So we
> > > > > > should either keep it as is or change original design of TM and attach
> > > > > > thread to VM before attaching it to TM. In that case we will have
> > > > > > valid JNIEnv which can be passed to jthread_atatch. We need to think
> > > > > > over it twice before changing something....
> > > > >
> > > > > Right. For jthread_attach, JNIenv needs to be changed from being input
> > > > > parameter to being the output parameter. The way how JNIenv is
> > > > > obtained by TM should be vm_attach() event.
> > > > OK, JNIEnv is output parameter. And it obtained by vm_attach(). This
> > > > is exactly like I do in the patch. What I don't understand is how
> > > > jthread_attach knows to which VM the thread should be attached? Do you
> > > > suggest calling vm_attach first to create JNIEnv it pass it to
> > > > jthread_attach?
> > > >
> > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > 4) Original classlib hythread do not use hythread_library_t in arguments,
> > > > > > > It uses following code:
> > > > > > >
> > > > > > > hythread_library_t lib = GLOBAL_DATA (default_library);
> > > > > > > or
> > > > > > > hythread_library_t library = thread->library;
> > > > > > >
> > > > > > > So could you please use the same mechanism and remove hythread_*_ex >functions.
> > > > > > Let's see if classlib's hythread needs changing first. It seems for me
> > > > > > such code prevents us from having multi VM.
> > > > > >
> > > > > > >
> > > > > > > 5. You introduce more then one jni env, but still use global variable for it.
> > > > > > > So all changes like following:
> > > > > > > - JNIEnv *jenv = (JNIEnv*)jni_native_intf;
> > > > > > > + JNIEnv *jenv = jni_native_intf;
> > > > > > >
> > > > > > > should be like:
> > > > > > > - JNIEnv *jenv = (JNIEnv*)jni_native_intf;
> > > > > > > + JNIEnv *jenv = get_jni_env(jthread_self());
> > > > > >
> > > > > > Ok, I see. I agree that global jni_native_intf should not be used.
> > > > > > There was simple reason why I altered such lines. Because I changed
> > > > > > the type of jni_native_intf and no casting operator is needed now. To
> > > > > > be honest I think get_jni_env(jthread_self()) can be good as temporary
> > > > > > solution only. Lets wait for design of multi VM and fix it according
> > > > > > to it.
> > > > >
> > > > > While we are in JNI code, we always have the JNIenv (at least
> > > > > initially it comes from Java code). If we consider VM code as if it
> > > > > was a JNI application, then it seems like we should be just passing
> > > > > JNIEnv as a parameter to all functions in VM. Or, we can be taking it
> > > > > from TLS (via jthread_self()), depending on which way is faster...
> > > > Agree.
> > > >
> > > > >
> > > > > >
> > > > > > >
> > > > > > > 6). And small remarks:
> > > > > > > +jint vm_init1(JavaVM_Internal * java_vm, JavaVMInitArgs * vm_arguments);
> > > > > > > +jint vm_init2(JNIEnv_Internal * jni_env);
> > > > > > > Could you make names more meaningful, then 1,2,3...?
> > > > > > Ok, will do that.
> > > > > >
> > > > > > >
> > > > > > > class VM_thread {
> > > > > > > ...
> > > > > > > + JNIEnv_Internal * jni_env;
> > > > > > > The jthread already has the jni_env pointer, you do not need to
> > > > > > > duplicate it here.
> > > > > > > forexample by using jthread_get_JNI_env(jthread_self());
> > > > > >
> > > > > > Yes I know. I don't see any problems here. Some times it is much more
> > > > > > convenient to get JNIEnv from VM_thread structure (and faster) instead
> > > > > > of doing jthread_get_JNI_env(jthread_self()). So I need strong
> > > > > > arguments for removing it. Again it seems that should be addressed in
> > > > > > design of multi VM. So lets forget about it for a while...
> > > > >
> > > > > I think that the data duplication would always serve as a potential
> > > > > source of errors - while updating one copy of object, you may forget
> > > > > to update the other, often resulting into a strange behavior of the
> > > > > whole application. Let's see what are the specific performance
> > > > > concerns that have to be addressed. To get VM_thread structure, you
> > > > > would eventually go to the TLS, just like
> > > > > jthread_get_JNI_env(jthread_self() would do.
> > > > If there is already VM_thread structure for some reasons then there
> > > > will be no extra access to TLS. It is definitely much more in
> > > > jthread_get_JNI_env(jthread_self() than just one TLS access and one
> > > > dereferncing. I don't think it is a really big problem now. Do you
> > > > agree to look at this later. I guess multi VM implementation will
> > > > alter it in any case.
> > > >
> > > > Thanks
> > > > Evgueni
> > > >
> > > > >
> > > > > Thanks,
> > > > > Andrey.
> > > > >
> > > > > >
> > > > > > Evgueni
> > > > > > >
> > > > > > > Thanks
> > > > > > > Artem
> > > > > > >
> > > > > > > On 9/28/06, Evgueni Brevnov <ev...@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.
> > > > > > > >
> > > > > > > > Thanks
> > > > > > > > Evgueni
> > > > > > > >
> > > > > > > > On 9/28/06, Geir Magnusson Jr. <ge...@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 <we...@gmail.com> wrote:
> > > > > > > > > >> On 9/26/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> > > > > > > > > >> >
> > > > > > > > > >> > On 9/27/06, Andrey Chernyshev <a....@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
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > ---------------------------------------------------------------------
> > > > > > > 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
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Andrey Chernyshev
> > > > > 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
> > >
> > >
> >
> >
> > --
> > Andrey Chernyshev
> > 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
>
>
--
Andrey Chernyshev
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
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
Posted by Evgueni Brevnov <ev...@gmail.com>.
On 10/3/06, Andrey Chernyshev <a....@gmail.com> wrote:
> On 10/2/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> > Andrey,
> >
> > Just to be clear.... I agree with you it is more convenient if
> > jthread_create takes JNIEnv instead of JavaVM. It reflects that
> > current thread has been attached already. Do you think it makes sense
> > to get rid of JNIEnv and use jthread_get_JNI_env in that case?
>
> The jthread_* layer is designed like if it were a regular JNI
> application which is meant to be called from the Java code, hence
> every function on that layer receives JNIenv. We can probably get rid
> of the JNEnv parameter for jthread_* functions, assuming that TM can
> always extract JNIenv for the current thread with
> jthread_get_JNI_env().
> My only concern would be the performance - once the JNIenv is already
> known for the native part of the kernel classes impl, it must be
> cheaper to pass JNIEnv to TM as an extra parameter rather than extract
> it from the TLS again.
> Other than that, I see no strong advantages in keeping JNIEnv parameter.
>
>
> > Regarding jthread_attach. I still didn't get your point.... Clarify it
> > please if you think jhread_attach should be modified.
>
> Sorry for being not clear: I think for jthread_attach, we have two options:
> 1) Make JNIEnv input parameter - it must be new JNIEnv that VM
> pre-allocates for the new Java thread. jthread_attach would just
> associate it with the current thread.
>
> 2) Obtain JNIEnv via vm_attach() callback. In this case, if
> vm_attach() callback implementation needs to know for which JavaVM new
> JNIenv has to be allocated, then we'll need to add JavaVM as input
> parameter for jthread_attach().
> I think both options should be fine, (1) would probably keep TM
> interface a bit lighter, though (2) may look more closer to the JNI
> invocation API idea.
> So I think adding JavaVM specifically for jthread_attach may make
> sense given the explanation you provided earlier.
>
> The concern I would have regarding the proposed jthread_attach
> implementation is a call to vm_create_jthread() - this call introduces
> an extra dependency of TM on vmcore that I'd prefer to be avoided. In
> the original version, jthread_attach() was taking jthread argument of
> the already prepared j.l.Thread.
I understand your concern. Unfortunately I don't see what we can do
here. Let me explain. In the beginning you have an unattached native
thread. To be able to call java code (which is required for
constructing j.l.Thread instance) the thread should be attached first.
To be specific it should be attached to VM by calling vm_attach which
will return a valid JNIEnv It is valid to use JNI from that moment.
Obtained JNIEnv can be used to execute java code and create j.l.Thread
instance. Since we do vm_attach in jthread_attach we need to do
vm_create_jthread inside jthread_atach as well.
Of course it can be an alternative to do vm_attach and
vm_create_jthread outside of TM right before jthread_attach. Sure it
will reduce one dependence between VM and TM. But it seems like
artificial action for me just because of dependency....
> Do you think it makes sense to replace a single jthread parameter with
> a variety of stuff (like thread group, name)? It seems the only
> purpose of at these args is to be passed back to VM for
> vm_jthread_create(). I would suggest to change this and try doing
> either of:
> 1) Make signature of jthread_attach with 3 args, JavaVM, jthread and the daemon.
Why do you want to pass daemon to TM but thread's name and group. Just
because current TM doesn't need such information? What if it is
required to get thread name later? Say by introducing
jthread_get_name... What will you do in that case? Let me guess you
will call j.l.Thread.getName. Right. Ok! In that case I see no
problems to call j.l.Thread.isDaemon. Do you agree? So it doesn't
seems to be a good design to pass only part of the information to
jthread_atach. Lets look at the signature of AttachCurrentThread. It
takes exactly these three parameters (daemon, name, group) passed as a
structure. I was thinking about having exactly the same structure as
third parameter of jthread_attach but it occured to be more convinient
to pass them seperatly. Although I don't see strong reasons against
having a structure a third parameter.
> 2) Move the implementation of vm_create_jtrhead() to
> thread_java_basic.c - could it be written in pure JNI without using
> internal VM API like class_alloc_new_object()?
Yes, this can be done but it doesn't fix the problem. You still need
to know about internal constructor of j.l.Thread
Thanks
Evgueni
>
>
> Thanks,
> Andrey.
>
> >
> > Thank you
> > Evgueni
> >
> > On 10/2/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> > > On 9/29/06, Andrey Chernyshev <a....@gmail.com> wrote:
> > > > On 9/29/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> > > > > Artem,
> > > > >
> > > > > Thank you for your feedback.... find my inlined.....
> > > > >
> > > > > On 9/29/06, Artem Aliev <ar...@gmail.com> wrote:
> > > > > > Evgueni,
> > > > > >
> > > > > > I got most of your changes, but still disagree with all
> > > > > > hythread/jthread interface changes. Could leave interface unchanged.
> > > > > > See following possible solutions, that could solve the same problems
> > > > > > without interface changes.
> > > > > >
> > > > > >
> > > > > > 1) daemon attribute is a java specific. (Andrey mentioned this already).
> > > > > > Could you please move it back. to the jthread layer. It is better
> > > > > > to rename
> > > > > > hythread_wait_for_all_nondaemon_threads() to
> > > > > > jthread_wait_for_all_nondaemon_threads().
> > > > > Ok, I see no problems to move "daemon" to java layer. In that case:
> > > > > 1) I will move hythread_wait_for_all_nondaemon_threads() from
> > > > > thread_init.c to one which implements java layer.
> > > > > 2) I will move daemon field from HyThread structure.
> > > > >
> > > > > Agree?
> > > >
> > > > Sounds good to me.
> > >
> > > OK, will do that.
> > >
> > > >
> > > >
> > > > >
> > > > > >
> > > > > > 2) JavaVM could be retrieved from JNIEnv by jni_get_java_vm(). So
> > > > > > let the jthread_create() and others to use JNIEnv (that is passed from
> > > > > > java native method).
> > > > > > The vm_attach could get old JNI env and create new one for the new thread.
> > > > > > The first JNIEnv is created in CreateVM call and could be passed to
> > > > > > the first thread at startup.
> > > > > No, no, no. I completely disagree with that!!! Why do you like JNIEnv
> > > > > but JavaVM. Why do you think that passing JavaVM instead of JNIEnv
> > > > > makes TM less modular? I don't see any difference here.... It seems
> > > > > for me like a big big hack to grab JNIEnv from another thread and pass
> > > > > it to jthread_attach to perform operations in the current thread.
> > > >
> > > > TM needs to know JNIEnv, mainly for managing the references to
> > > > objects, throwing exceptions and calling run() method of a new thread.
> > > > JNI spec proposes that JNIEnv is valid within the given thread, this
> > > > is why TM holds the JNIEnv pointer at the moment. This is why TM likes
> > > > the JNIEnv.
> > > >
> > > > Having the JNIEnv, one is able to get JavaVM but not vise versa. This
> > > > is why TM doesn't like the JavaVM :)
> > > I see your point. Only one note this is true for already attached threads...
> > >
> > > >
> > > > I agree with you that there is a design flaw that the JNIEnv is copied
> > > > from the parent thread to a child thread during thread creation. I
> > > > think it could be resolved via vm_attach() hook - with this event, VM
> > > > might tell the TM what the JNIEnv pointer for new thread should be. I
> > > > think you did that by extending the vm_attach() call with the JNIEnv**
> > > > argument.
> > > >
> > > > What is not completely clear is, why do you have to pass the JavaVM
> > > > forth and back, once from VM to TM, and then back from TM to VM again?
> > > >
> > > > If you need to know in jthread_attach, which particular VM vm_attach()
> > > > event is coming from, you could have vm_attach like
> > > > vm_attach(JNIEnv* currentThreadEnv, JNIEnv** newThreadEnv).
> > > I'm a little bit confused.....Current thread hasn't been attached yet.
> > > So there is no JNIEnv for it yet. How it can be passed as the first
> > > parameter to vm_attach()?
> > >
> > > > Then you will be always able to get the JavaVM from the JNIEnv.
> > > > The only difference is that you are currently doing JNIEnv->JavaVM
> > > > conversion in the VMThreadManager, but why can't you just do this in
> > > > vm_attach() without changing the interface of the TM?
> > > > So far JavaVM really looks like an extra knowledge that TM doesn't
> > > > have to be aware of.
> > > >
> > > > > Moreover there is no JNIEnv when main thread attaches to VM. So we
> > > > > should either keep it as is or change original design of TM and attach
> > > > > thread to VM before attaching it to TM. In that case we will have
> > > > > valid JNIEnv which can be passed to jthread_atatch. We need to think
> > > > > over it twice before changing something....
> > > >
> > > > Right. For jthread_attach, JNIenv needs to be changed from being input
> > > > parameter to being the output parameter. The way how JNIenv is
> > > > obtained by TM should be vm_attach() event.
> > > OK, JNIEnv is output parameter. And it obtained by vm_attach(). This
> > > is exactly like I do in the patch. What I don't understand is how
> > > jthread_attach knows to which VM the thread should be attached? Do you
> > > suggest calling vm_attach first to create JNIEnv it pass it to
> > > jthread_attach?
> > >
> > > >
> > > > >
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > > 4) Original classlib hythread do not use hythread_library_t in arguments,
> > > > > > It uses following code:
> > > > > >
> > > > > > hythread_library_t lib = GLOBAL_DATA (default_library);
> > > > > > or
> > > > > > hythread_library_t library = thread->library;
> > > > > >
> > > > > > So could you please use the same mechanism and remove hythread_*_ex >functions.
> > > > > Let's see if classlib's hythread needs changing first. It seems for me
> > > > > such code prevents us from having multi VM.
> > > > >
> > > > > >
> > > > > > 5. You introduce more then one jni env, but still use global variable for it.
> > > > > > So all changes like following:
> > > > > > - JNIEnv *jenv = (JNIEnv*)jni_native_intf;
> > > > > > + JNIEnv *jenv = jni_native_intf;
> > > > > >
> > > > > > should be like:
> > > > > > - JNIEnv *jenv = (JNIEnv*)jni_native_intf;
> > > > > > + JNIEnv *jenv = get_jni_env(jthread_self());
> > > > >
> > > > > Ok, I see. I agree that global jni_native_intf should not be used.
> > > > > There was simple reason why I altered such lines. Because I changed
> > > > > the type of jni_native_intf and no casting operator is needed now. To
> > > > > be honest I think get_jni_env(jthread_self()) can be good as temporary
> > > > > solution only. Lets wait for design of multi VM and fix it according
> > > > > to it.
> > > >
> > > > While we are in JNI code, we always have the JNIenv (at least
> > > > initially it comes from Java code). If we consider VM code as if it
> > > > was a JNI application, then it seems like we should be just passing
> > > > JNIEnv as a parameter to all functions in VM. Or, we can be taking it
> > > > from TLS (via jthread_self()), depending on which way is faster...
> > > Agree.
> > >
> > > >
> > > > >
> > > > > >
> > > > > > 6). And small remarks:
> > > > > > +jint vm_init1(JavaVM_Internal * java_vm, JavaVMInitArgs * vm_arguments);
> > > > > > +jint vm_init2(JNIEnv_Internal * jni_env);
> > > > > > Could you make names more meaningful, then 1,2,3...?
> > > > > Ok, will do that.
> > > > >
> > > > > >
> > > > > > class VM_thread {
> > > > > > ...
> > > > > > + JNIEnv_Internal * jni_env;
> > > > > > The jthread already has the jni_env pointer, you do not need to
> > > > > > duplicate it here.
> > > > > > forexample by using jthread_get_JNI_env(jthread_self());
> > > > >
> > > > > Yes I know. I don't see any problems here. Some times it is much more
> > > > > convenient to get JNIEnv from VM_thread structure (and faster) instead
> > > > > of doing jthread_get_JNI_env(jthread_self()). So I need strong
> > > > > arguments for removing it. Again it seems that should be addressed in
> > > > > design of multi VM. So lets forget about it for a while...
> > > >
> > > > I think that the data duplication would always serve as a potential
> > > > source of errors - while updating one copy of object, you may forget
> > > > to update the other, often resulting into a strange behavior of the
> > > > whole application. Let's see what are the specific performance
> > > > concerns that have to be addressed. To get VM_thread structure, you
> > > > would eventually go to the TLS, just like
> > > > jthread_get_JNI_env(jthread_self() would do.
> > > If there is already VM_thread structure for some reasons then there
> > > will be no extra access to TLS. It is definitely much more in
> > > jthread_get_JNI_env(jthread_self() than just one TLS access and one
> > > dereferncing. I don't think it is a really big problem now. Do you
> > > agree to look at this later. I guess multi VM implementation will
> > > alter it in any case.
> > >
> > > Thanks
> > > Evgueni
> > >
> > > >
> > > > Thanks,
> > > > Andrey.
> > > >
> > > > >
> > > > > Evgueni
> > > > > >
> > > > > > Thanks
> > > > > > Artem
> > > > > >
> > > > > > On 9/28/06, Evgueni Brevnov <ev...@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.
> > > > > > >
> > > > > > > Thanks
> > > > > > > Evgueni
> > > > > > >
> > > > > > > On 9/28/06, Geir Magnusson Jr. <ge...@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 <we...@gmail.com> wrote:
> > > > > > > > >> On 9/26/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> > > > > > > > >> >
> > > > > > > > >> > On 9/27/06, Andrey Chernyshev <a....@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
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > ---------------------------------------------------------------------
> > > > > > 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
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Andrey Chernyshev
> > > > 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
> >
> >
>
>
> --
> Andrey Chernyshev
> 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
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
Posted by Andrey Chernyshev <a....@gmail.com>.
On 10/2/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> Andrey,
>
> Just to be clear.... I agree with you it is more convenient if
> jthread_create takes JNIEnv instead of JavaVM. It reflects that
> current thread has been attached already. Do you think it makes sense
> to get rid of JNIEnv and use jthread_get_JNI_env in that case?
The jthread_* layer is designed like if it were a regular JNI
application which is meant to be called from the Java code, hence
every function on that layer receives JNIenv. We can probably get rid
of the JNEnv parameter for jthread_* functions, assuming that TM can
always extract JNIenv for the current thread with
jthread_get_JNI_env().
My only concern would be the performance - once the JNIenv is already
known for the native part of the kernel classes impl, it must be
cheaper to pass JNIEnv to TM as an extra parameter rather than extract
it from the TLS again.
Other than that, I see no strong advantages in keeping JNIEnv parameter.
> Regarding jthread_attach. I still didn't get your point.... Clarify it
> please if you think jhread_attach should be modified.
Sorry for being not clear: I think for jthread_attach, we have two options:
1) Make JNIEnv input parameter - it must be new JNIEnv that VM
pre-allocates for the new Java thread. jthread_attach would just
associate it with the current thread.
2) Obtain JNIEnv via vm_attach() callback. In this case, if
vm_attach() callback implementation needs to know for which JavaVM new
JNIenv has to be allocated, then we'll need to add JavaVM as input
parameter for jthread_attach().
I think both options should be fine, (1) would probably keep TM
interface a bit lighter, though (2) may look more closer to the JNI
invocation API idea.
So I think adding JavaVM specifically for jthread_attach may make
sense given the explanation you provided earlier.
The concern I would have regarding the proposed jthread_attach
implementation is a call to vm_create_jthread() - this call introduces
an extra dependency of TM on vmcore that I'd prefer to be avoided. In
the original version, jthread_attach() was taking jthread argument of
the already prepared j.l.Thread.
Do you think it makes sense to replace a single jthread parameter with
a variety of stuff (like thread group, name)? It seems the only
purpose of at these args is to be passed back to VM for
vm_jthread_create(). I would suggest to change this and try doing
either of:
1) Make signature of jthread_attach with 3 args, JavaVM, jthread and the daemon.
2) Move the implementation of vm_create_jtrhead() to
thread_java_basic.c - could it be written in pure JNI without using
internal VM API like class_alloc_new_object()?
Thanks,
Andrey.
>
> Thank you
> Evgueni
>
> On 10/2/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> > On 9/29/06, Andrey Chernyshev <a....@gmail.com> wrote:
> > > On 9/29/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> > > > Artem,
> > > >
> > > > Thank you for your feedback.... find my inlined.....
> > > >
> > > > On 9/29/06, Artem Aliev <ar...@gmail.com> wrote:
> > > > > Evgueni,
> > > > >
> > > > > I got most of your changes, but still disagree with all
> > > > > hythread/jthread interface changes. Could leave interface unchanged.
> > > > > See following possible solutions, that could solve the same problems
> > > > > without interface changes.
> > > > >
> > > > >
> > > > > 1) daemon attribute is a java specific. (Andrey mentioned this already).
> > > > > Could you please move it back. to the jthread layer. It is better
> > > > > to rename
> > > > > hythread_wait_for_all_nondaemon_threads() to
> > > > > jthread_wait_for_all_nondaemon_threads().
> > > > Ok, I see no problems to move "daemon" to java layer. In that case:
> > > > 1) I will move hythread_wait_for_all_nondaemon_threads() from
> > > > thread_init.c to one which implements java layer.
> > > > 2) I will move daemon field from HyThread structure.
> > > >
> > > > Agree?
> > >
> > > Sounds good to me.
> >
> > OK, will do that.
> >
> > >
> > >
> > > >
> > > > >
> > > > > 2) JavaVM could be retrieved from JNIEnv by jni_get_java_vm(). So
> > > > > let the jthread_create() and others to use JNIEnv (that is passed from
> > > > > java native method).
> > > > > The vm_attach could get old JNI env and create new one for the new thread.
> > > > > The first JNIEnv is created in CreateVM call and could be passed to
> > > > > the first thread at startup.
> > > > No, no, no. I completely disagree with that!!! Why do you like JNIEnv
> > > > but JavaVM. Why do you think that passing JavaVM instead of JNIEnv
> > > > makes TM less modular? I don't see any difference here.... It seems
> > > > for me like a big big hack to grab JNIEnv from another thread and pass
> > > > it to jthread_attach to perform operations in the current thread.
> > >
> > > TM needs to know JNIEnv, mainly for managing the references to
> > > objects, throwing exceptions and calling run() method of a new thread.
> > > JNI spec proposes that JNIEnv is valid within the given thread, this
> > > is why TM holds the JNIEnv pointer at the moment. This is why TM likes
> > > the JNIEnv.
> > >
> > > Having the JNIEnv, one is able to get JavaVM but not vise versa. This
> > > is why TM doesn't like the JavaVM :)
> > I see your point. Only one note this is true for already attached threads...
> >
> > >
> > > I agree with you that there is a design flaw that the JNIEnv is copied
> > > from the parent thread to a child thread during thread creation. I
> > > think it could be resolved via vm_attach() hook - with this event, VM
> > > might tell the TM what the JNIEnv pointer for new thread should be. I
> > > think you did that by extending the vm_attach() call with the JNIEnv**
> > > argument.
> > >
> > > What is not completely clear is, why do you have to pass the JavaVM
> > > forth and back, once from VM to TM, and then back from TM to VM again?
> > >
> > > If you need to know in jthread_attach, which particular VM vm_attach()
> > > event is coming from, you could have vm_attach like
> > > vm_attach(JNIEnv* currentThreadEnv, JNIEnv** newThreadEnv).
> > I'm a little bit confused.....Current thread hasn't been attached yet.
> > So there is no JNIEnv for it yet. How it can be passed as the first
> > parameter to vm_attach()?
> >
> > > Then you will be always able to get the JavaVM from the JNIEnv.
> > > The only difference is that you are currently doing JNIEnv->JavaVM
> > > conversion in the VMThreadManager, but why can't you just do this in
> > > vm_attach() without changing the interface of the TM?
> > > So far JavaVM really looks like an extra knowledge that TM doesn't
> > > have to be aware of.
> > >
> > > > Moreover there is no JNIEnv when main thread attaches to VM. So we
> > > > should either keep it as is or change original design of TM and attach
> > > > thread to VM before attaching it to TM. In that case we will have
> > > > valid JNIEnv which can be passed to jthread_atatch. We need to think
> > > > over it twice before changing something....
> > >
> > > Right. For jthread_attach, JNIenv needs to be changed from being input
> > > parameter to being the output parameter. The way how JNIenv is
> > > obtained by TM should be vm_attach() event.
> > OK, JNIEnv is output parameter. And it obtained by vm_attach(). This
> > is exactly like I do in the patch. What I don't understand is how
> > jthread_attach knows to which VM the thread should be attached? Do you
> > suggest calling vm_attach first to create JNIEnv it pass it to
> > jthread_attach?
> >
> > >
> > > >
> > > >
> > > >
> > > > >
> > > > >
> > > > > 4) Original classlib hythread do not use hythread_library_t in arguments,
> > > > > It uses following code:
> > > > >
> > > > > hythread_library_t lib = GLOBAL_DATA (default_library);
> > > > > or
> > > > > hythread_library_t library = thread->library;
> > > > >
> > > > > So could you please use the same mechanism and remove hythread_*_ex >functions.
> > > > Let's see if classlib's hythread needs changing first. It seems for me
> > > > such code prevents us from having multi VM.
> > > >
> > > > >
> > > > > 5. You introduce more then one jni env, but still use global variable for it.
> > > > > So all changes like following:
> > > > > - JNIEnv *jenv = (JNIEnv*)jni_native_intf;
> > > > > + JNIEnv *jenv = jni_native_intf;
> > > > >
> > > > > should be like:
> > > > > - JNIEnv *jenv = (JNIEnv*)jni_native_intf;
> > > > > + JNIEnv *jenv = get_jni_env(jthread_self());
> > > >
> > > > Ok, I see. I agree that global jni_native_intf should not be used.
> > > > There was simple reason why I altered such lines. Because I changed
> > > > the type of jni_native_intf and no casting operator is needed now. To
> > > > be honest I think get_jni_env(jthread_self()) can be good as temporary
> > > > solution only. Lets wait for design of multi VM and fix it according
> > > > to it.
> > >
> > > While we are in JNI code, we always have the JNIenv (at least
> > > initially it comes from Java code). If we consider VM code as if it
> > > was a JNI application, then it seems like we should be just passing
> > > JNIEnv as a parameter to all functions in VM. Or, we can be taking it
> > > from TLS (via jthread_self()), depending on which way is faster...
> > Agree.
> >
> > >
> > > >
> > > > >
> > > > > 6). And small remarks:
> > > > > +jint vm_init1(JavaVM_Internal * java_vm, JavaVMInitArgs * vm_arguments);
> > > > > +jint vm_init2(JNIEnv_Internal * jni_env);
> > > > > Could you make names more meaningful, then 1,2,3...?
> > > > Ok, will do that.
> > > >
> > > > >
> > > > > class VM_thread {
> > > > > ...
> > > > > + JNIEnv_Internal * jni_env;
> > > > > The jthread already has the jni_env pointer, you do not need to
> > > > > duplicate it here.
> > > > > forexample by using jthread_get_JNI_env(jthread_self());
> > > >
> > > > Yes I know. I don't see any problems here. Some times it is much more
> > > > convenient to get JNIEnv from VM_thread structure (and faster) instead
> > > > of doing jthread_get_JNI_env(jthread_self()). So I need strong
> > > > arguments for removing it. Again it seems that should be addressed in
> > > > design of multi VM. So lets forget about it for a while...
> > >
> > > I think that the data duplication would always serve as a potential
> > > source of errors - while updating one copy of object, you may forget
> > > to update the other, often resulting into a strange behavior of the
> > > whole application. Let's see what are the specific performance
> > > concerns that have to be addressed. To get VM_thread structure, you
> > > would eventually go to the TLS, just like
> > > jthread_get_JNI_env(jthread_self() would do.
> > If there is already VM_thread structure for some reasons then there
> > will be no extra access to TLS. It is definitely much more in
> > jthread_get_JNI_env(jthread_self() than just one TLS access and one
> > dereferncing. I don't think it is a really big problem now. Do you
> > agree to look at this later. I guess multi VM implementation will
> > alter it in any case.
> >
> > Thanks
> > Evgueni
> >
> > >
> > > Thanks,
> > > Andrey.
> > >
> > > >
> > > > Evgueni
> > > > >
> > > > > Thanks
> > > > > Artem
> > > > >
> > > > > On 9/28/06, Evgueni Brevnov <ev...@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.
> > > > > >
> > > > > > Thanks
> > > > > > Evgueni
> > > > > >
> > > > > > On 9/28/06, Geir Magnusson Jr. <ge...@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 <we...@gmail.com> wrote:
> > > > > > > >> On 9/26/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> > > > > > > >> >
> > > > > > > >> > On 9/27/06, Andrey Chernyshev <a....@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
> > > > > >
> > > > > >
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > 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
> > > >
> > > >
> > >
> > >
> > > --
> > > Andrey Chernyshev
> > > 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
>
>
--
Andrey Chernyshev
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
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
Posted by Evgueni Brevnov <ev...@gmail.com>.
Andrey,
Just to be clear.... I agree with you it is more convenient if
jthread_create takes JNIEnv instead of JavaVM. It reflects that
current thread has been attached already. Do you think it makes sense
to get rid of JNIEnv and use jthread_get_JNI_env in that case?
Regarding jthread_attach. I still didn't get your point.... Clarify it
please if you think jhread_attach should be modified.
Thank you
Evgueni
On 10/2/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> On 9/29/06, Andrey Chernyshev <a....@gmail.com> wrote:
> > On 9/29/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> > > Artem,
> > >
> > > Thank you for your feedback.... find my inlined.....
> > >
> > > On 9/29/06, Artem Aliev <ar...@gmail.com> wrote:
> > > > Evgueni,
> > > >
> > > > I got most of your changes, but still disagree with all
> > > > hythread/jthread interface changes. Could leave interface unchanged.
> > > > See following possible solutions, that could solve the same problems
> > > > without interface changes.
> > > >
> > > >
> > > > 1) daemon attribute is a java specific. (Andrey mentioned this already).
> > > > Could you please move it back. to the jthread layer. It is better
> > > > to rename
> > > > hythread_wait_for_all_nondaemon_threads() to
> > > > jthread_wait_for_all_nondaemon_threads().
> > > Ok, I see no problems to move "daemon" to java layer. In that case:
> > > 1) I will move hythread_wait_for_all_nondaemon_threads() from
> > > thread_init.c to one which implements java layer.
> > > 2) I will move daemon field from HyThread structure.
> > >
> > > Agree?
> >
> > Sounds good to me.
>
> OK, will do that.
>
> >
> >
> > >
> > > >
> > > > 2) JavaVM could be retrieved from JNIEnv by jni_get_java_vm(). So
> > > > let the jthread_create() and others to use JNIEnv (that is passed from
> > > > java native method).
> > > > The vm_attach could get old JNI env and create new one for the new thread.
> > > > The first JNIEnv is created in CreateVM call and could be passed to
> > > > the first thread at startup.
> > > No, no, no. I completely disagree with that!!! Why do you like JNIEnv
> > > but JavaVM. Why do you think that passing JavaVM instead of JNIEnv
> > > makes TM less modular? I don't see any difference here.... It seems
> > > for me like a big big hack to grab JNIEnv from another thread and pass
> > > it to jthread_attach to perform operations in the current thread.
> >
> > TM needs to know JNIEnv, mainly for managing the references to
> > objects, throwing exceptions and calling run() method of a new thread.
> > JNI spec proposes that JNIEnv is valid within the given thread, this
> > is why TM holds the JNIEnv pointer at the moment. This is why TM likes
> > the JNIEnv.
> >
> > Having the JNIEnv, one is able to get JavaVM but not vise versa. This
> > is why TM doesn't like the JavaVM :)
> I see your point. Only one note this is true for already attached threads...
>
> >
> > I agree with you that there is a design flaw that the JNIEnv is copied
> > from the parent thread to a child thread during thread creation. I
> > think it could be resolved via vm_attach() hook - with this event, VM
> > might tell the TM what the JNIEnv pointer for new thread should be. I
> > think you did that by extending the vm_attach() call with the JNIEnv**
> > argument.
> >
> > What is not completely clear is, why do you have to pass the JavaVM
> > forth and back, once from VM to TM, and then back from TM to VM again?
> >
> > If you need to know in jthread_attach, which particular VM vm_attach()
> > event is coming from, you could have vm_attach like
> > vm_attach(JNIEnv* currentThreadEnv, JNIEnv** newThreadEnv).
> I'm a little bit confused.....Current thread hasn't been attached yet.
> So there is no JNIEnv for it yet. How it can be passed as the first
> parameter to vm_attach()?
>
> > Then you will be always able to get the JavaVM from the JNIEnv.
> > The only difference is that you are currently doing JNIEnv->JavaVM
> > conversion in the VMThreadManager, but why can't you just do this in
> > vm_attach() without changing the interface of the TM?
> > So far JavaVM really looks like an extra knowledge that TM doesn't
> > have to be aware of.
> >
> > > Moreover there is no JNIEnv when main thread attaches to VM. So we
> > > should either keep it as is or change original design of TM and attach
> > > thread to VM before attaching it to TM. In that case we will have
> > > valid JNIEnv which can be passed to jthread_atatch. We need to think
> > > over it twice before changing something....
> >
> > Right. For jthread_attach, JNIenv needs to be changed from being input
> > parameter to being the output parameter. The way how JNIenv is
> > obtained by TM should be vm_attach() event.
> OK, JNIEnv is output parameter. And it obtained by vm_attach(). This
> is exactly like I do in the patch. What I don't understand is how
> jthread_attach knows to which VM the thread should be attached? Do you
> suggest calling vm_attach first to create JNIEnv it pass it to
> jthread_attach?
>
> >
> > >
> > >
> > >
> > > >
> > > >
> > > > 4) Original classlib hythread do not use hythread_library_t in arguments,
> > > > It uses following code:
> > > >
> > > > hythread_library_t lib = GLOBAL_DATA (default_library);
> > > > or
> > > > hythread_library_t library = thread->library;
> > > >
> > > > So could you please use the same mechanism and remove hythread_*_ex >functions.
> > > Let's see if classlib's hythread needs changing first. It seems for me
> > > such code prevents us from having multi VM.
> > >
> > > >
> > > > 5. You introduce more then one jni env, but still use global variable for it.
> > > > So all changes like following:
> > > > - JNIEnv *jenv = (JNIEnv*)jni_native_intf;
> > > > + JNIEnv *jenv = jni_native_intf;
> > > >
> > > > should be like:
> > > > - JNIEnv *jenv = (JNIEnv*)jni_native_intf;
> > > > + JNIEnv *jenv = get_jni_env(jthread_self());
> > >
> > > Ok, I see. I agree that global jni_native_intf should not be used.
> > > There was simple reason why I altered such lines. Because I changed
> > > the type of jni_native_intf and no casting operator is needed now. To
> > > be honest I think get_jni_env(jthread_self()) can be good as temporary
> > > solution only. Lets wait for design of multi VM and fix it according
> > > to it.
> >
> > While we are in JNI code, we always have the JNIenv (at least
> > initially it comes from Java code). If we consider VM code as if it
> > was a JNI application, then it seems like we should be just passing
> > JNIEnv as a parameter to all functions in VM. Or, we can be taking it
> > from TLS (via jthread_self()), depending on which way is faster...
> Agree.
>
> >
> > >
> > > >
> > > > 6). And small remarks:
> > > > +jint vm_init1(JavaVM_Internal * java_vm, JavaVMInitArgs * vm_arguments);
> > > > +jint vm_init2(JNIEnv_Internal * jni_env);
> > > > Could you make names more meaningful, then 1,2,3...?
> > > Ok, will do that.
> > >
> > > >
> > > > class VM_thread {
> > > > ...
> > > > + JNIEnv_Internal * jni_env;
> > > > The jthread already has the jni_env pointer, you do not need to
> > > > duplicate it here.
> > > > forexample by using jthread_get_JNI_env(jthread_self());
> > >
> > > Yes I know. I don't see any problems here. Some times it is much more
> > > convenient to get JNIEnv from VM_thread structure (and faster) instead
> > > of doing jthread_get_JNI_env(jthread_self()). So I need strong
> > > arguments for removing it. Again it seems that should be addressed in
> > > design of multi VM. So lets forget about it for a while...
> >
> > I think that the data duplication would always serve as a potential
> > source of errors - while updating one copy of object, you may forget
> > to update the other, often resulting into a strange behavior of the
> > whole application. Let's see what are the specific performance
> > concerns that have to be addressed. To get VM_thread structure, you
> > would eventually go to the TLS, just like
> > jthread_get_JNI_env(jthread_self() would do.
> If there is already VM_thread structure for some reasons then there
> will be no extra access to TLS. It is definitely much more in
> jthread_get_JNI_env(jthread_self() than just one TLS access and one
> dereferncing. I don't think it is a really big problem now. Do you
> agree to look at this later. I guess multi VM implementation will
> alter it in any case.
>
> Thanks
> Evgueni
>
> >
> > Thanks,
> > Andrey.
> >
> > >
> > > Evgueni
> > > >
> > > > Thanks
> > > > Artem
> > > >
> > > > On 9/28/06, Evgueni Brevnov <ev...@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.
> > > > >
> > > > > Thanks
> > > > > Evgueni
> > > > >
> > > > > On 9/28/06, Geir Magnusson Jr. <ge...@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 <we...@gmail.com> wrote:
> > > > > > >> On 9/26/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> > > > > > >> >
> > > > > > >> > On 9/27/06, Andrey Chernyshev <a....@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
> > > > >
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > 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
> > >
> > >
> >
> >
> > --
> > Andrey Chernyshev
> > 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
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
Posted by Evgueni Brevnov <ev...@gmail.com>.
On 9/29/06, Andrey Chernyshev <a....@gmail.com> wrote:
> On 9/29/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> > Artem,
> >
> > Thank you for your feedback.... find my inlined.....
> >
> > On 9/29/06, Artem Aliev <ar...@gmail.com> wrote:
> > > Evgueni,
> > >
> > > I got most of your changes, but still disagree with all
> > > hythread/jthread interface changes. Could leave interface unchanged.
> > > See following possible solutions, that could solve the same problems
> > > without interface changes.
> > >
> > >
> > > 1) daemon attribute is a java specific. (Andrey mentioned this already).
> > > Could you please move it back. to the jthread layer. It is better
> > > to rename
> > > hythread_wait_for_all_nondaemon_threads() to
> > > jthread_wait_for_all_nondaemon_threads().
> > Ok, I see no problems to move "daemon" to java layer. In that case:
> > 1) I will move hythread_wait_for_all_nondaemon_threads() from
> > thread_init.c to one which implements java layer.
> > 2) I will move daemon field from HyThread structure.
> >
> > Agree?
>
> Sounds good to me.
OK, will do that.
>
>
> >
> > >
> > > 2) JavaVM could be retrieved from JNIEnv by jni_get_java_vm(). So
> > > let the jthread_create() and others to use JNIEnv (that is passed from
> > > java native method).
> > > The vm_attach could get old JNI env and create new one for the new thread.
> > > The first JNIEnv is created in CreateVM call and could be passed to
> > > the first thread at startup.
> > No, no, no. I completely disagree with that!!! Why do you like JNIEnv
> > but JavaVM. Why do you think that passing JavaVM instead of JNIEnv
> > makes TM less modular? I don't see any difference here.... It seems
> > for me like a big big hack to grab JNIEnv from another thread and pass
> > it to jthread_attach to perform operations in the current thread.
>
> TM needs to know JNIEnv, mainly for managing the references to
> objects, throwing exceptions and calling run() method of a new thread.
> JNI spec proposes that JNIEnv is valid within the given thread, this
> is why TM holds the JNIEnv pointer at the moment. This is why TM likes
> the JNIEnv.
>
> Having the JNIEnv, one is able to get JavaVM but not vise versa. This
> is why TM doesn't like the JavaVM :)
I see your point. Only one note this is true for already attached threads...
>
> I agree with you that there is a design flaw that the JNIEnv is copied
> from the parent thread to a child thread during thread creation. I
> think it could be resolved via vm_attach() hook - with this event, VM
> might tell the TM what the JNIEnv pointer for new thread should be. I
> think you did that by extending the vm_attach() call with the JNIEnv**
> argument.
>
> What is not completely clear is, why do you have to pass the JavaVM
> forth and back, once from VM to TM, and then back from TM to VM again?
>
> If you need to know in jthread_attach, which particular VM vm_attach()
> event is coming from, you could have vm_attach like
> vm_attach(JNIEnv* currentThreadEnv, JNIEnv** newThreadEnv).
I'm a little bit confused.....Current thread hasn't been attached yet.
So there is no JNIEnv for it yet. How it can be passed as the first
parameter to vm_attach()?
> Then you will be always able to get the JavaVM from the JNIEnv.
> The only difference is that you are currently doing JNIEnv->JavaVM
> conversion in the VMThreadManager, but why can't you just do this in
> vm_attach() without changing the interface of the TM?
> So far JavaVM really looks like an extra knowledge that TM doesn't
> have to be aware of.
>
> > Moreover there is no JNIEnv when main thread attaches to VM. So we
> > should either keep it as is or change original design of TM and attach
> > thread to VM before attaching it to TM. In that case we will have
> > valid JNIEnv which can be passed to jthread_atatch. We need to think
> > over it twice before changing something....
>
> Right. For jthread_attach, JNIenv needs to be changed from being input
> parameter to being the output parameter. The way how JNIenv is
> obtained by TM should be vm_attach() event.
OK, JNIEnv is output parameter. And it obtained by vm_attach(). This
is exactly like I do in the patch. What I don't understand is how
jthread_attach knows to which VM the thread should be attached? Do you
suggest calling vm_attach first to create JNIEnv it pass it to
jthread_attach?
>
> >
> >
> >
> > >
> > >
> > > 4) Original classlib hythread do not use hythread_library_t in arguments,
> > > It uses following code:
> > >
> > > hythread_library_t lib = GLOBAL_DATA (default_library);
> > > or
> > > hythread_library_t library = thread->library;
> > >
> > > So could you please use the same mechanism and remove hythread_*_ex >functions.
> > Let's see if classlib's hythread needs changing first. It seems for me
> > such code prevents us from having multi VM.
> >
> > >
> > > 5. You introduce more then one jni env, but still use global variable for it.
> > > So all changes like following:
> > > - JNIEnv *jenv = (JNIEnv*)jni_native_intf;
> > > + JNIEnv *jenv = jni_native_intf;
> > >
> > > should be like:
> > > - JNIEnv *jenv = (JNIEnv*)jni_native_intf;
> > > + JNIEnv *jenv = get_jni_env(jthread_self());
> >
> > Ok, I see. I agree that global jni_native_intf should not be used.
> > There was simple reason why I altered such lines. Because I changed
> > the type of jni_native_intf and no casting operator is needed now. To
> > be honest I think get_jni_env(jthread_self()) can be good as temporary
> > solution only. Lets wait for design of multi VM and fix it according
> > to it.
>
> While we are in JNI code, we always have the JNIenv (at least
> initially it comes from Java code). If we consider VM code as if it
> was a JNI application, then it seems like we should be just passing
> JNIEnv as a parameter to all functions in VM. Or, we can be taking it
> from TLS (via jthread_self()), depending on which way is faster...
Agree.
>
> >
> > >
> > > 6). And small remarks:
> > > +jint vm_init1(JavaVM_Internal * java_vm, JavaVMInitArgs * vm_arguments);
> > > +jint vm_init2(JNIEnv_Internal * jni_env);
> > > Could you make names more meaningful, then 1,2,3...?
> > Ok, will do that.
> >
> > >
> > > class VM_thread {
> > > ...
> > > + JNIEnv_Internal * jni_env;
> > > The jthread already has the jni_env pointer, you do not need to
> > > duplicate it here.
> > > forexample by using jthread_get_JNI_env(jthread_self());
> >
> > Yes I know. I don't see any problems here. Some times it is much more
> > convenient to get JNIEnv from VM_thread structure (and faster) instead
> > of doing jthread_get_JNI_env(jthread_self()). So I need strong
> > arguments for removing it. Again it seems that should be addressed in
> > design of multi VM. So lets forget about it for a while...
>
> I think that the data duplication would always serve as a potential
> source of errors - while updating one copy of object, you may forget
> to update the other, often resulting into a strange behavior of the
> whole application. Let's see what are the specific performance
> concerns that have to be addressed. To get VM_thread structure, you
> would eventually go to the TLS, just like
> jthread_get_JNI_env(jthread_self() would do.
If there is already VM_thread structure for some reasons then there
will be no extra access to TLS. It is definitely much more in
jthread_get_JNI_env(jthread_self() than just one TLS access and one
dereferncing. I don't think it is a really big problem now. Do you
agree to look at this later. I guess multi VM implementation will
alter it in any case.
Thanks
Evgueni
>
> Thanks,
> Andrey.
>
> >
> > Evgueni
> > >
> > > Thanks
> > > Artem
> > >
> > > On 9/28/06, Evgueni Brevnov <ev...@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.
> > > >
> > > > Thanks
> > > > Evgueni
> > > >
> > > > On 9/28/06, Geir Magnusson Jr. <ge...@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 <we...@gmail.com> wrote:
> > > > > >> On 9/26/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> > > > > >> >
> > > > > >> > On 9/27/06, Andrey Chernyshev <a....@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
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > 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
> >
> >
>
>
> --
> Andrey Chernyshev
> 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
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
Posted by Andrey Chernyshev <a....@gmail.com>.
On 9/29/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> Artem,
>
> Thank you for your feedback.... find my inlined.....
>
> On 9/29/06, Artem Aliev <ar...@gmail.com> wrote:
> > Evgueni,
> >
> > I got most of your changes, but still disagree with all
> > hythread/jthread interface changes. Could leave interface unchanged.
> > See following possible solutions, that could solve the same problems
> > without interface changes.
> >
> >
> > 1) daemon attribute is a java specific. (Andrey mentioned this already).
> > Could you please move it back. to the jthread layer. It is better
> > to rename
> > hythread_wait_for_all_nondaemon_threads() to
> > jthread_wait_for_all_nondaemon_threads().
> Ok, I see no problems to move "daemon" to java layer. In that case:
> 1) I will move hythread_wait_for_all_nondaemon_threads() from
> thread_init.c to one which implements java layer.
> 2) I will move daemon field from HyThread structure.
>
> Agree?
Sounds good to me.
>
> >
> > 2) JavaVM could be retrieved from JNIEnv by jni_get_java_vm(). So
> > let the jthread_create() and others to use JNIEnv (that is passed from
> > java native method).
> > The vm_attach could get old JNI env and create new one for the new thread.
> > The first JNIEnv is created in CreateVM call and could be passed to
> > the first thread at startup.
> No, no, no. I completely disagree with that!!! Why do you like JNIEnv
> but JavaVM. Why do you think that passing JavaVM instead of JNIEnv
> makes TM less modular? I don't see any difference here.... It seems
> for me like a big big hack to grab JNIEnv from another thread and pass
> it to jthread_attach to perform operations in the current thread.
TM needs to know JNIEnv, mainly for managing the references to
objects, throwing exceptions and calling run() method of a new thread.
JNI spec proposes that JNIEnv is valid within the given thread, this
is why TM holds the JNIEnv pointer at the moment. This is why TM likes
the JNIEnv.
Having the JNIEnv, one is able to get JavaVM but not vise versa. This
is why TM doesn't like the JavaVM :)
I agree with you that there is a design flaw that the JNIEnv is copied
from the parent thread to a child thread during thread creation. I
think it could be resolved via vm_attach() hook - with this event, VM
might tell the TM what the JNIEnv pointer for new thread should be. I
think you did that by extending the vm_attach() call with the JNIEnv**
argument.
What is not completely clear is, why do you have to pass the JavaVM
forth and back, once from VM to TM, and then back from TM to VM again?
If you need to know in jthread_attach, which particular VM vm_attach()
event is coming from, you could have vm_attach like
vm_attach(JNIEnv* currentThreadEnv, JNIEnv** newThreadEnv).
Then you will be always able to get the JavaVM from the JNIEnv.
The only difference is that you are currently doing JNIEnv->JavaVM
conversion in the VMThreadManager, but why can't you just do this in
vm_attach() without changing the interface of the TM?
So far JavaVM really looks like an extra knowledge that TM doesn't
have to be aware of.
> Moreover there is no JNIEnv when main thread attaches to VM. So we
> should either keep it as is or change original design of TM and attach
> thread to VM before attaching it to TM. In that case we will have
> valid JNIEnv which can be passed to jthread_atatch. We need to think
> over it twice before changing something....
Right. For jthread_attach, JNIenv needs to be changed from being input
parameter to being the output parameter. The way how JNIenv is
obtained by TM should be vm_attach() event.
>
>
>
> >
> >
> > 4) Original classlib hythread do not use hythread_library_t in arguments,
> > It uses following code:
> >
> > hythread_library_t lib = GLOBAL_DATA (default_library);
> > or
> > hythread_library_t library = thread->library;
> >
> > So could you please use the same mechanism and remove hythread_*_ex >functions.
> Let's see if classlib's hythread needs changing first. It seems for me
> such code prevents us from having multi VM.
>
> >
> > 5. You introduce more then one jni env, but still use global variable for it.
> > So all changes like following:
> > - JNIEnv *jenv = (JNIEnv*)jni_native_intf;
> > + JNIEnv *jenv = jni_native_intf;
> >
> > should be like:
> > - JNIEnv *jenv = (JNIEnv*)jni_native_intf;
> > + JNIEnv *jenv = get_jni_env(jthread_self());
>
> Ok, I see. I agree that global jni_native_intf should not be used.
> There was simple reason why I altered such lines. Because I changed
> the type of jni_native_intf and no casting operator is needed now. To
> be honest I think get_jni_env(jthread_self()) can be good as temporary
> solution only. Lets wait for design of multi VM and fix it according
> to it.
While we are in JNI code, we always have the JNIenv (at least
initially it comes from Java code). If we consider VM code as if it
was a JNI application, then it seems like we should be just passing
JNIEnv as a parameter to all functions in VM. Or, we can be taking it
from TLS (via jthread_self()), depending on which way is faster...
>
> >
> > 6). And small remarks:
> > +jint vm_init1(JavaVM_Internal * java_vm, JavaVMInitArgs * vm_arguments);
> > +jint vm_init2(JNIEnv_Internal * jni_env);
> > Could you make names more meaningful, then 1,2,3...?
> Ok, will do that.
>
> >
> > class VM_thread {
> > ...
> > + JNIEnv_Internal * jni_env;
> > The jthread already has the jni_env pointer, you do not need to
> > duplicate it here.
> > forexample by using jthread_get_JNI_env(jthread_self());
>
> Yes I know. I don't see any problems here. Some times it is much more
> convenient to get JNIEnv from VM_thread structure (and faster) instead
> of doing jthread_get_JNI_env(jthread_self()). So I need strong
> arguments for removing it. Again it seems that should be addressed in
> design of multi VM. So lets forget about it for a while...
I think that the data duplication would always serve as a potential
source of errors - while updating one copy of object, you may forget
to update the other, often resulting into a strange behavior of the
whole application. Let's see what are the specific performance
concerns that have to be addressed. To get VM_thread structure, you
would eventually go to the TLS, just like
jthread_get_JNI_env(jthread_self() would do.
Thanks,
Andrey.
>
> Evgueni
> >
> > Thanks
> > Artem
> >
> > On 9/28/06, Evgueni Brevnov <ev...@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.
> > >
> > > Thanks
> > > Evgueni
> > >
> > > On 9/28/06, Geir Magnusson Jr. <ge...@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 <we...@gmail.com> wrote:
> > > > >> On 9/26/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> > > > >> >
> > > > >> > On 9/27/06, Andrey Chernyshev <a....@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
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > 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
>
>
--
Andrey Chernyshev
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
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
Posted by Evgueni Brevnov <ev...@gmail.com>.
Artem,
Thank you for your feedback.... find my inlined.....
On 9/29/06, Artem Aliev <ar...@gmail.com> wrote:
> Evgueni,
>
> I got most of your changes, but still disagree with all
> hythread/jthread interface changes. Could leave interface unchanged.
> See following possible solutions, that could solve the same problems
> without interface changes.
>
>
> 1) daemon attribute is a java specific. (Andrey mentioned this already).
> Could you please move it back. to the jthread layer. It is better
> to rename
> hythread_wait_for_all_nondaemon_threads() to
> jthread_wait_for_all_nondaemon_threads().
Ok, I see no problems to move "daemon" to java layer. In that case:
1) I will move hythread_wait_for_all_nondaemon_threads() from
thread_init.c to one which implements java layer.
2) I will move daemon field from HyThread structure.
Agree?
>
> 2) JavaVM could be retrieved from JNIEnv by jni_get_java_vm(). So
> let the jthread_create() and others to use JNIEnv (that is passed from
> java native method).
> The vm_attach could get old JNI env and create new one for the new thread.
> The first JNIEnv is created in CreateVM call and could be passed to
> the first thread at startup.
No, no, no. I completely disagree with that!!! Why do you like JNIEnv
but JavaVM. Why do you think that passing JavaVM instead of JNIEnv
makes TM less modular? I don't see any difference here.... It seems
for me like a big big hack to grab JNIEnv from another thread and pass
it to jthread_attach to perform operations in the current thread.
Moreover there is no JNIEnv when main thread attaches to VM. So we
should either keep it as is or change original design of TM and attach
thread to VM before attaching it to TM. In that case we will have
valid JNIEnv which can be passed to jthread_atatch. We need to think
over it twice before changing something....
>
>
> 4) Original classlib hythread do not use hythread_library_t in arguments,
> It uses following code:
>
> hythread_library_t lib = GLOBAL_DATA (default_library);
> or
> hythread_library_t library = thread->library;
>
> So could you please use the same mechanism and remove hythread_*_ex >functions.
Let's see if classlib's hythread needs changing first. It seems for me
such code prevents us from having multi VM.
>
> 5. You introduce more then one jni env, but still use global variable for it.
> So all changes like following:
> - JNIEnv *jenv = (JNIEnv*)jni_native_intf;
> + JNIEnv *jenv = jni_native_intf;
>
> should be like:
> - JNIEnv *jenv = (JNIEnv*)jni_native_intf;
> + JNIEnv *jenv = get_jni_env(jthread_self());
Ok, I see. I agree that global jni_native_intf should not be used.
There was simple reason why I altered such lines. Because I changed
the type of jni_native_intf and no casting operator is needed now. To
be honest I think get_jni_env(jthread_self()) can be good as temporary
solution only. Lets wait for design of multi VM and fix it according
to it.
>
> 6). And small remarks:
> +jint vm_init1(JavaVM_Internal * java_vm, JavaVMInitArgs * vm_arguments);
> +jint vm_init2(JNIEnv_Internal * jni_env);
> Could you make names more meaningful, then 1,2,3...?
Ok, will do that.
>
> class VM_thread {
> ...
> + JNIEnv_Internal * jni_env;
> The jthread already has the jni_env pointer, you do not need to
> duplicate it here.
> forexample by using jthread_get_JNI_env(jthread_self());
Yes I know. I don't see any problems here. Some times it is much more
convenient to get JNIEnv from VM_thread structure (and faster) instead
of doing jthread_get_JNI_env(jthread_self()). So I need strong
arguments for removing it. Again it seems that should be addressed in
design of multi VM. So lets forget about it for a while...
Evgueni
>
> Thanks
> Artem
>
> On 9/28/06, Evgueni Brevnov <ev...@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.
> >
> > Thanks
> > Evgueni
> >
> > On 9/28/06, Geir Magnusson Jr. <ge...@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 <we...@gmail.com> wrote:
> > > >> On 9/26/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> > > >> >
> > > >> > On 9/27/06, Andrey Chernyshev <a....@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
> >
> >
>
> ---------------------------------------------------------------------
> 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
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
Posted by Artem Aliev <ar...@gmail.com>.
Evgueni,
I got most of your changes, but still disagree with all
hythread/jthread interface changes. Could leave interface unchanged.
See following possible solutions, that could solve the same problems
without interface changes.
1) daemon attribute is a java specific. (Andrey mentioned this already).
Could you please move it back. to the jthread layer. It is better
to rename
hythread_wait_for_all_nondaemon_threads() to
jthread_wait_for_all_nondaemon_threads().
2) JavaVM could be retrieved from JNIEnv by jni_get_java_vm(). So
let the jthread_create() and others to use JNIEnv (that is passed from
java native method).
The vm_attach could get old JNI env and create new one for the new thread.
The first JNIEnv is created in CreateVM call and could be passed to
the first thread at startup.
4) Original classlib hythread do not use hythread_library_t in arguments,
It uses following code:
hythread_library_t lib = GLOBAL_DATA (default_library);
or
hythread_library_t library = thread->library;
So could you please use the same mechanism and remove hythread_*_ex functions.
5. You introduce more then one jni env, but still use global variable for it.
So all changes like following:
- JNIEnv *jenv = (JNIEnv*)jni_native_intf;
+ JNIEnv *jenv = jni_native_intf;
should be like:
- JNIEnv *jenv = (JNIEnv*)jni_native_intf;
+ JNIEnv *jenv = get_jni_env(jthread_self());
6). And small remarks:
+jint vm_init1(JavaVM_Internal * java_vm, JavaVMInitArgs * vm_arguments);
+jint vm_init2(JNIEnv_Internal * jni_env);
Could you make names more meaningful, then 1,2,3...?
class VM_thread {
...
+ JNIEnv_Internal * jni_env;
The jthread already has the jni_env pointer, you do not need to
duplicate it here.
forexample by using jthread_get_JNI_env(jthread_self());
Thanks
Artem
On 9/28/06, Evgueni Brevnov <ev...@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.
>
> Thanks
> Evgueni
>
> On 9/28/06, Geir Magnusson Jr. <ge...@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 <we...@gmail.com> wrote:
> > >> On 9/26/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> > >> >
> > >> > On 9/27/06, Andrey Chernyshev <a....@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
>
>
---------------------------------------------------------------------
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
Re: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
Posted by Alexey Varlamov <al...@gmail.com>.
+1 for commit.
I didn't see any major flaw in the patch; at the same time this
functionality is vital for further progress in many areas. And due to
large scale of the patch it will become stale quite soon.
We certainly should avoid this style in future: need to discuss design
earlier and split changes to smaller chanks when possible. But now I
vote for faster progress.
--
Regards,
Alexey
2006/9/28, Evgueni Brevnov <ev...@gmail.com>:
> 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. <ge...@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 <we...@gmail.com> wrote:
> > >> On 9/26/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> > >> >
> > >> > On 9/27/06, Andrey Chernyshev <a....@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
>
>
---------------------------------------------------------------------
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