harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrey Yakushev" <andrey.yakus...@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 13:21:16 GMT
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
>

Mime
View raw message