Re: [drlvm][jvmti] thread_java_basic.c::thread_end_count ---- is it necessary that this variable be accurate?

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