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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: > On 1/26/07, Andrey Yakushev <[EMAIL PROTECTED]> 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 >
