Yes, of course. Are you going to prepare corresponding patch?
Thanks, Andrey On 1/30/07, Angela Lin <[EMAIL PROTECTED]> 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 <[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 > >
