harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Angela Lin" <alin.harm...@gmail.com>
Subject Re: [vmi] thread library - lang.management digression
Date Tue, 30 Jan 2007 16:24:57 GMT
I think createThreadInfoImpl should be removed.

You should also be able to remove the native helpers that are only
used by the java implementation of getThreadInfoImpl():

getObjectThreadIsBlockedOnImpl
getThreadOwningObjectImpl
isSuspendedImpl
getThreadWaitedCountImpl
getThreadWaitedTimeImpl
getThreadBlockedTimeImpl
getThreadBlockedCountImpl

Thanks,
Angela


On 1/30/07, Andrey Yakushev <andrey.yakushev@gmail.com> wrote:
> 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
> >

Mime
View raw message