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 16:43:06 GMT
Yes, of course. Are you going to prepare corresponding patch?

Thanks,
Andrey


On 1/30/07, Angela Lin <alin.harmony@gmail.com> wrote:
> 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