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: [vmi] thread library - lang.management digression
Date Tue, 30 Jan 2007 10:17:52 GMT

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?


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

View raw message