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 Fri, 26 Jan 2007 15:40:55 GMT
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