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.
As for ThreadInfo, spec specially states:
"This thread information class is designed for use in monitoring of
the system, not for synchronization control."
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?
Thanks,
Andrey
On 1/25/07, Angela Lin <[EMAIL PROTECTED]> wrote:
Thanks for the clarification.
Hope you don't mind if I digress onto some discussion of the
ThreadMXBean native interface.
The native interface has some problems that I've recently spent time
fixing in our implementation. I suspect these problems would be
relevant to DRLVM as well.
The most problematic natives are the ones used for implementing
ThreadMXBean.getThreadInfo(): e.g. getObjectThreadIsBlockedOnImpl()
and getThreadOwningObjectImpl() et al.
The java code for j.l.m implements getThreadInfo() by calling a bunch
of get queries. It does something like:
state = thread.getState()
if (state == BLOCKED) {
lockObj = getObjectThreadIsBlockedOnImpl()
lockObjOwner = getThreadOwningObjectImpl()
}
... but the examined thread is running the entire time and the
resulting set of {state, lockObj, lockObjOwner} can be nonsense. You
can get results like a BLOCKED thread having no blocking object.
I could only fix this in our implementation by dropping
getThreadInfoImpl() itself down to the native level.
Angela
On 1/25/07, Andrey Yakushev <[EMAIL PROTECTED]> wrote:
> Angela wrote:
>
> > I think someone else had suggested that parts of lang-management might
> be considered kernel classes. Any thoughts?
>
> AFAIK current j.l.management module doesn't have native code at all.
> For threading part it requires 25 native methods, most of them are
> get/set queries. I think all of them could be added to kernel classes
> as suggested in HARMONY-1821 and HARMONY-2059. Thus j.l.management
> will not depend on hythr at all.
>
>
> The list of native functions:
>
> findMonitorDeadlockedThreadsImpl
> getAllThreadIdsImpl
> getDaemonThreadCountImpl
> getPeakThreadCountImpl
> getThreadCountImpl
> getThreadCpuTimeImpl
> getThreadByIdImpl
> getObjectThreadIsBlockedOnImpl
> getThreadOwningObjectImpl
> isSuspendedImpl
> getThreadWaitedCountImpl
> getThreadWaitedTimeImpl
> getThreadBlockedTimeImpl
> getThreadBlockedCountImpl
> createThreadInfoImpl
> getThreadUserTimeImpl
> getTotalStartedThreadCountImpl
> isCurrentThreadCpuTimeSupportedImpl
> isThreadContentionMonitoringEnabledImpl
> isThreadContentionMonitoringSupportedImpl
> isThreadCpuTimeEnabledImpl
> isThreadCpuTimeSupportedImpl
> resetPeakThreadCountImpl
> setThreadContentionMonitoringEnabledImpl
> setThreadCpuTimeEnabledImpl
>
>
> Thanks,
> Andrey
>
>
> On 1/25/07, Angela Lin <[EMAIL PROTECTED]> wrote:
> > I agree with this proposal.
> >
> > For most of the classlib, the classlib-threading contract should be
> > straightforward.
> >
> > There are a couple grey areas that concern me:
> > - j.u.concurrent
> > - j.l.management (ThreadMXBean etc.)
> > j.u.concurrent seems to need some special VM support, and ThreadMXBean
> > seems to need to know way too much about the VM threading model to be
> > satisfied by a simple contract.
> >
>
> > I think someone else had suggested that parts of lang-management might
> > be considered kernel classes. Any thoughts?
> >
> > Angela
--
Angela Lin, IBM Ottawa Software Lab
