harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrey Yakushev" <andrey.yakus...@gmail.com>
Subject Re: [vmi] thread library - lang.management digression
Date Fri, 26 Jan 2007 10:53:58 GMT
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 <alin.harmony@gmail.com> 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 <andrey.yakushev@gmail.com> 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 <alin.harmony@gmail.com> 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
>

Mime
View raw message