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
