Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (herse.apache.org: domain of andrey.yakushev@gmail.com
 designates 66.249.92.173 as permitted sender)
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=TeKkrkg9JS62HG2fqrtEJzz8i2QiORW4o5sl/rqP0rf8Z2ARvIzWqP5k3vHfw7+ETSWNDjYwx/+2H065wEp4bRoKc4+J8wRjLeHppgT2y/QgYFweKtyxZ0IXMr5uT2xt4RpD/bUhGHyNR1Vy4tQ7oimEzZwSK4JvEPWoHAPzeR0=
Message-ID: <3c7e1c080701300217h200343f4ub8d2eba7e1388fdd@mail.gmail.com>
Date: Tue, 30 Jan 2007 13:17:52 +0300
From: "Andrey Yakushev" <andrey.yakushev@gmail.com>
To: dev@harmony.apache.org
Subject: Re: [vmi] thread library - lang.management digression
In-Reply-To: <3ae04f990701260740t4d85f5f6qe0216f336b784573@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: <3ae04f990701251112x623d538cxc9e4cc8a83c0ef46@mail.gmail.com>
	 <3c7e1c080701260253v2fef171hdae4ce870025d503@mail.gmail.com>
	 <3ae04f990701260740t4d85f5f6qe0216f336b784573@mail.gmail.com>

Angela,

I looked through JDK6 and found that newly added getThreadInfo variant
contains not only mentioned statement: "This might be an expensive
operation" but also: "This method is designed for troubleshooting
use". I agree that "troubleshooting" is not only "monitoring" and
probably requires consistent state. It is strange because
troubleshooting usually was the JVMTI responsibitity.

So now I think that adding getThreadInfoImpl is a good idea. Will we
remove createThreadInfoImpl?

Thanks,
Andrey


On 1/26/07, Angela Lin <alin.harmony@gmail.com> wrote:
> On 1/26/07, Andrey Yakushev <andrey.yakushev@gmail.com> wrote:
> > My understanding was that j.l.m should avoid influence on VM as much
> > as possible. Thus it shouldn't add additional locks for queries. Of
> > course, it leads to inconsistency in multivalued requests, but it is
> > expected behaviour.
>
> My impression is that users do expect consistency. I think users value
> consistency over performance. I don't think users would look at the
> spec and recognize that ThreadInfo would be nonsense unless the thread
> is deadlocked or otherwise suspended.
>
> I think it's important that j.l.m not influence the VM when it's not
> used, but that it's acceptable to introduce expense when it is used.
>
> For example:
> - A number of ThreadMXBean queries, including getThreadInfo() in JDK6,
> are documented as, "This might be an expensive operation."
>
> - Some parts of the ThreadInfo, such as the stack trace, can't be
> retrieved without some kind of lock on the thread anyway (maybe this
> isn't true of your implementation?)
>
> - Other functions, like thread CPU usage and contention monitoring,
> can be enabled/disabled because they introduce additional VM expense
> if enabled.
>
> If you use an aggregate get native for getThreadInfoImpl(), your
> implementation is still free to not do any locking if you wish to
> tolerate inconsistency. However, using a bunch of individual get
> natives makes it impossible for an implementation to enforce
> consistency if it prefers to.
>
> >
> > As for ThreadInfo, spec specially states:
> > "This thread information class is designed for use in monitoring of
> > the system, not for synchronization control."
>
> ThreadInfo shouldn't be used for synchronization control because the
> ThreadInfo is stale by the time the user application gets it.
>
> >
> > That doesn't mean that I insist on having kernel classes interface at
> > native functions level. I even prefer to have interface as a set of
> > classes; current dependency analysis showed that they are:
> >
> > ManagementUtils
> > MemoryManagerMXBeanImpl
> > OpenTypeMappingIHandler
> >
> > What's your opinion?
>
> I'm not knowledgeable enough about the rest of j.l.m to have an
> opinion. I hope the class library guys can jump in here?
>
> >
> > Thanks,
> > Andrey
>
> Thanks.
>
> Regards,
> Angela
>