harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject Re: [drlvm][jvmti] thread_java_basic.c::thread_end_count ---- is it necessary that this variable be accurate?
Date Fri, 30 Mar 2007 15:53:02 GMT
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 <andrey.yakushev@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 <weldonwjw@gmail.com> wrote:
> > On 3/28/07, Andrey Yakushev <andrey.yakushev@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 <gshimansky@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

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