From dev-return-25590-apmail-harmony-dev-archive=harmony.apache.org@harmony.apache.org Mon Apr 02 12:56:28 2007 Return-Path: Delivered-To: apmail-harmony-dev-archive@www.apache.org Received: (qmail 97704 invoked from network); 2 Apr 2007 12:56:27 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 2 Apr 2007 12:56:27 -0000 Received: (qmail 32208 invoked by uid 500); 2 Apr 2007 12:56:32 -0000 Delivered-To: apmail-harmony-dev-archive@harmony.apache.org Received: (qmail 32179 invoked by uid 500); 2 Apr 2007 12:56:32 -0000 Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@harmony.apache.org Delivered-To: mailing list dev@harmony.apache.org Received: (qmail 32169 invoked by uid 99); 2 Apr 2007 12:56:32 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 Apr 2007 05:56:32 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of andrey.yakushev@gmail.com designates 66.249.92.174 as permitted sender) Received: from [66.249.92.174] (HELO ug-out-1314.google.com) (66.249.92.174) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 Apr 2007 05:56:23 -0700 Received: by ug-out-1314.google.com with SMTP id z36so1364728uge for ; Mon, 02 Apr 2007 05:56:01 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=XKVmMFabH+4oU9g2SriEt8ssGLZ4rLlFxsNePdTsrnZHeSL/sPCVzTqwGgPg6E7JeddDJO/q8Y6QVr+U5fFPu88uL09o39zcLYFH0Woxp11P4TZOlyfWMccMPX3cWMpQ/Cq9ZvUgWPpJp38K8bMIwj5geLpneSQxv5JVl+ZOa3s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=uMozJksfg+Ange9HyHRD2Qr8x68uhts8ccbt8lEHG1X+yFRBityP2W7mV35BwpRJmVgxwecwYtzqViB7DQXrgIxjHJaXWHlkXjmMTzE2qXrgKCa02ivXRtq5Mb9izjTn34A1k9M0QX4frJD/ILTsW6y7VJnJ9FCT4b0/p9jm2+0= Received: by 10.82.113.6 with SMTP id l6mr7752343buc.1175518561192; Mon, 02 Apr 2007 05:56:01 -0700 (PDT) Received: by 10.82.100.20 with HTTP; Mon, 2 Apr 2007 05:56:01 -0700 (PDT) Message-ID: <3c7e1c080704020556r14135695uc02445fd1b14f336@mail.gmail.com> Date: Mon, 2 Apr 2007 16:56:01 +0400 From: "Andrey Yakushev" To: dev@harmony.apache.org Subject: Re: [drlvm][jvmti] thread_java_basic.c::thread_end_count ---- is it necessary that this variable be accurate? In-Reply-To: <4dd1f3f00703300853x42977e77v82f0f1b6603019ae@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4dd1f3f00703272049l6aa3b3a8ya4128e6851e7e02a@mail.gmail.com> <3c7e1c080703280435y20e6e047qb69f4dba2f5bf33e@mail.gmail.com> <4dd1f3f00703291116o4bead78fu5bf44924d36489da@mail.gmail.com> <3c7e1c080703300621o6c410151q64b266f153b81b20@mail.gmail.com> <4dd1f3f00703300853x42977e77v82f0f1b6603019ae@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org On 3/30/07, Weldon Washburn 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 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 wrote: > > > On 3/28/07, Andrey Yakushev 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 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 >