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
