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 Thu, 25 Jan 2007 19:12:15 GMT
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