You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Weldon Washburn <we...@gmail.com> on 2007/03/28 05:49:07 UTC
[drlvm][jvmti] thread_java_basic.c::thread_end_count ---- is it necessary that this variable be accurate?
Maybe I am misunderstanding the code. It looks like "alive_thread_count--;"
could be executed concurrently by multiple threads and consequently end up
with an incorrect value. Is it OK to have an approximate value?
--
Weldon Washburn
Re: [drlvm][jvmti] thread_java_basic.c::thread_end_count ---- is it necessary that this variable be accurate?
Posted by Andrey Yakushev <an...@gmail.com>.
On 3/30/07, Weldon Washburn <we...@gmail.com> wrote:
> hmm... I think what you are saying is that stale thread count data can lead
> to performance degradation. But it can not lead to correctness problem.
Yes
> If the above is true, my guess is that it will be a long while before drlvm
> matures such that this becomes an important peformance issue.
Right, I agree. So code should be corrected.
Thanks,
Andrey
> Does this
> make sense?
>
>
> On 3/30/07, Andrey Yakushev <an...@gmail.com> wrote:
> >
> > The "decision", as I understand it, is how to interpret the spec.
> >
> > Reasons to have another (not as "decided") interpretation:
> >
> > Because ThreadMXBean returns monitoring information it could be
> > obsolete and so incorrect just after the obtaining. It gives an
> > impression that bean can always return slightly incorrect information,
> > for example in cases when strict value obtaining leads to possible
> > performance degradation (adding synchronization to alive_thread_count
> > decrement). Spec also supports such interpretation, because has
> > statements like: "This method is designed ... not for synchronization
> > control" or "Some threads included in the returned array may have been
> > terminated when this method returns."
> >
> > Thanks,
> > Andrey
> >
> >
> > On 3/29/07, Weldon Washburn <we...@gmail.com> wrote:
> > > On 3/28/07, Andrey Yakushev <an...@gmail.com> wrote:
> > > >
> > > > Similar problem was discussed here, see
> > > >
> > > >
> > http://mail-archives.apache.org/mod_mbox/harmony-dev/200701.mbox/%3c3c7e1c080701300217h200343f4ub8d2eba7e1388fdd@mail.gmail.com%3e
> > > > .
> > > >
> > > > As I remember, the decision was to have strict value instead of
> > > > approximation. So we have to synchronize alive_thread_count decrement
> > > > and other similar places as Weldon correctly noted.
> > >
> > >
> > > wait. I am confused by "decision". Is this a issue of following the
> > spec
> > > for ThreadMXBean? Is this an issue of interpreting the ThreadMXBean
> > spec to
> > > say "accurate"? Or am I missing the point and this is something
> > entirely
> > > different.
> > >
> > > Thanks,
> > > > Andrey
> > > >
> > > >
> > > > On 3/28/07, Gregory Shimansky <gs...@gmail.com> wrote:
> > > > > Weldon Washburn wrote:
> > > > > > Maybe I am misunderstanding the code. It looks like
> > > > > > "alive_thread_count--;"
> > > > > > could be executed concurrently by multiple threads and
> > consequently
> > > > end up
> > > > > > with an incorrect value. Is it OK to have an approximate value?
> > > > >
> > > > > This variable is not used by JVMTI code, JVMTI doesn't deal with
> > > > > statistics. The code was added at revision 513013 from HARMONY-2059
> > and
> > > > > is an implementation of j.l.management.ThreadMXBean native part.
> > > > >
> > > > > Since this is just statistics, I think it may have an approximate
> > value.
> > > > >
> > > > > --
> > > > > Gregory
> > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Weldon Washburn
> > >
> >
>
>
>
> --
> Weldon Washburn
>
Re: [drlvm][jvmti] thread_java_basic.c::thread_end_count ---- is it necessary that this variable be accurate?
Posted by Weldon Washburn <we...@gmail.com>.
hmm... I think what you are saying is that stale thread count data can lead
to performance degradation. But it can not lead to correctness problem.
If the above is true, my guess is that it will be a long while before drlvm
matures such that this becomes an important peformance issue. Does this
make sense?
On 3/30/07, Andrey Yakushev <an...@gmail.com> wrote:
>
> The "decision", as I understand it, is how to interpret the spec.
>
> Reasons to have another (not as "decided") interpretation:
>
> Because ThreadMXBean returns monitoring information it could be
> obsolete and so incorrect just after the obtaining. It gives an
> impression that bean can always return slightly incorrect information,
> for example in cases when strict value obtaining leads to possible
> performance degradation (adding synchronization to alive_thread_count
> decrement). Spec also supports such interpretation, because has
> statements like: "This method is designed ... not for synchronization
> control" or "Some threads included in the returned array may have been
> terminated when this method returns."
>
> Thanks,
> Andrey
>
>
> On 3/29/07, Weldon Washburn <we...@gmail.com> wrote:
> > On 3/28/07, Andrey Yakushev <an...@gmail.com> wrote:
> > >
> > > Similar problem was discussed here, see
> > >
> > >
> http://mail-archives.apache.org/mod_mbox/harmony-dev/200701.mbox/%3c3c7e1c080701300217h200343f4ub8d2eba7e1388fdd@mail.gmail.com%3e
> > > .
> > >
> > > As I remember, the decision was to have strict value instead of
> > > approximation. So we have to synchronize alive_thread_count decrement
> > > and other similar places as Weldon correctly noted.
> >
> >
> > wait. I am confused by "decision". Is this a issue of following the
> spec
> > for ThreadMXBean? Is this an issue of interpreting the ThreadMXBean
> spec to
> > say "accurate"? Or am I missing the point and this is something
> entirely
> > different.
> >
> > Thanks,
> > > Andrey
> > >
> > >
> > > On 3/28/07, Gregory Shimansky <gs...@gmail.com> wrote:
> > > > Weldon Washburn wrote:
> > > > > Maybe I am misunderstanding the code. It looks like
> > > > > "alive_thread_count--;"
> > > > > could be executed concurrently by multiple threads and
> consequently
> > > end up
> > > > > with an incorrect value. Is it OK to have an approximate value?
> > > >
> > > > This variable is not used by JVMTI code, JVMTI doesn't deal with
> > > > statistics. The code was added at revision 513013 from HARMONY-2059
> and
> > > > is an implementation of j.l.management.ThreadMXBean native part.
> > > >
> > > > Since this is just statistics, I think it may have an approximate
> value.
> > > >
> > > > --
> > > > Gregory
> > > >
> > > >
> > >
> >
> >
> >
> > --
> > Weldon Washburn
> >
>
--
Weldon Washburn
Re: [drlvm][jvmti] thread_java_basic.c::thread_end_count ---- is it necessary that this variable be accurate?
Posted by Andrey Yakushev <an...@gmail.com>.
The "decision", as I understand it, is how to interpret the spec.
Reasons to have another (not as "decided") interpretation:
Because ThreadMXBean returns monitoring information it could be
obsolete and so incorrect just after the obtaining. It gives an
impression that bean can always return slightly incorrect information,
for example in cases when strict value obtaining leads to possible
performance degradation (adding synchronization to alive_thread_count
decrement). Spec also supports such interpretation, because has
statements like: "This method is designed ... not for synchronization
control" or "Some threads included in the returned array may have been
terminated when this method returns."
Thanks,
Andrey
On 3/29/07, Weldon Washburn <we...@gmail.com> wrote:
> On 3/28/07, Andrey Yakushev <an...@gmail.com> wrote:
> >
> > Similar problem was discussed here, see
> >
> > http://mail-archives.apache.org/mod_mbox/harmony-dev/200701.mbox/%3c3c7e1c080701300217h200343f4ub8d2eba7e1388fdd@mail.gmail.com%3e
> > .
> >
> > As I remember, the decision was to have strict value instead of
> > approximation. So we have to synchronize alive_thread_count decrement
> > and other similar places as Weldon correctly noted.
>
>
> wait. I am confused by "decision". Is this a issue of following the spec
> for ThreadMXBean? Is this an issue of interpreting the ThreadMXBean spec to
> say "accurate"? Or am I missing the point and this is something entirely
> different.
>
> Thanks,
> > Andrey
> >
> >
> > On 3/28/07, Gregory Shimansky <gs...@gmail.com> wrote:
> > > Weldon Washburn wrote:
> > > > Maybe I am misunderstanding the code. It looks like
> > > > "alive_thread_count--;"
> > > > could be executed concurrently by multiple threads and consequently
> > end up
> > > > with an incorrect value. Is it OK to have an approximate value?
> > >
> > > This variable is not used by JVMTI code, JVMTI doesn't deal with
> > > statistics. The code was added at revision 513013 from HARMONY-2059 and
> > > is an implementation of j.l.management.ThreadMXBean native part.
> > >
> > > Since this is just statistics, I think it may have an approximate value.
> > >
> > > --
> > > Gregory
> > >
> > >
> >
>
>
>
> --
> Weldon Washburn
>
Re: [drlvm][jvmti] thread_java_basic.c::thread_end_count ---- is it necessary that this variable be accurate?
Posted by Weldon Washburn <we...@gmail.com>.
On 3/28/07, Andrey Yakushev <an...@gmail.com> wrote:
>
> Similar problem was discussed here, see
>
> http://mail-archives.apache.org/mod_mbox/harmony-dev/200701.mbox/%3c3c7e1c080701300217h200343f4ub8d2eba7e1388fdd@mail.gmail.com%3e
> .
>
> As I remember, the decision was to have strict value instead of
> approximation. So we have to synchronize alive_thread_count decrement
> and other similar places as Weldon correctly noted.
wait. I am confused by "decision". Is this a issue of following the spec
for ThreadMXBean? Is this an issue of interpreting the ThreadMXBean spec to
say "accurate"? Or am I missing the point and this is something entirely
different.
Thanks,
> Andrey
>
>
> On 3/28/07, Gregory Shimansky <gs...@gmail.com> wrote:
> > Weldon Washburn wrote:
> > > Maybe I am misunderstanding the code. It looks like
> > > "alive_thread_count--;"
> > > could be executed concurrently by multiple threads and consequently
> end up
> > > with an incorrect value. Is it OK to have an approximate value?
> >
> > This variable is not used by JVMTI code, JVMTI doesn't deal with
> > statistics. The code was added at revision 513013 from HARMONY-2059 and
> > is an implementation of j.l.management.ThreadMXBean native part.
> >
> > Since this is just statistics, I think it may have an approximate value.
> >
> > --
> > Gregory
> >
> >
>
--
Weldon Washburn
Re: [drlvm][jvmti] thread_java_basic.c::thread_end_count ---- is it necessary that this variable be accurate?
Posted by Andrey Yakushev <an...@gmail.com>.
Similar problem was discussed here, see
http://mail-archives.apache.org/mod_mbox/harmony-dev/200701.mbox/%3c3c7e1c080701300217h200343f4ub8d2eba7e1388fdd@mail.gmail.com%3e.
As I remember, the decision was to have strict value instead of
approximation. So we have to synchronize alive_thread_count decrement
and other similar places as Weldon correctly noted.
Thanks,
Andrey
On 3/28/07, Gregory Shimansky <gs...@gmail.com> wrote:
> Weldon Washburn wrote:
> > Maybe I am misunderstanding the code. It looks like
> > "alive_thread_count--;"
> > could be executed concurrently by multiple threads and consequently end up
> > with an incorrect value. Is it OK to have an approximate value?
>
> This variable is not used by JVMTI code, JVMTI doesn't deal with
> statistics. The code was added at revision 513013 from HARMONY-2059 and
> is an implementation of j.l.management.ThreadMXBean native part.
>
> Since this is just statistics, I think it may have an approximate value.
>
> --
> Gregory
>
>
Re: [drlvm][jvmti] thread_java_basic.c::thread_end_count ---- is
it necessary that this variable be accurate?
Posted by Gregory Shimansky <gs...@gmail.com>.
Weldon Washburn wrote:
> Maybe I am misunderstanding the code. It looks like
> "alive_thread_count--;"
> could be executed concurrently by multiple threads and consequently end up
> with an incorrect value. Is it OK to have an approximate value?
This variable is not used by JVMTI code, JVMTI doesn't deal with
statistics. The code was added at revision 513013 from HARMONY-2059 and
is an implementation of j.l.management.ThreadMXBean native part.
Since this is just statistics, I think it may have an approximate value.
--
Gregory