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
Date Thu, 25 Jan 2007 17:24:07 GMT
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
>
> On 1/24/07, Tim Ellison <t.p.ellison@gmail.com> wrote:
> > Geir Magnusson Jr. wrote:
> > > On Jan 24, 2007, at 11:55 AM, Tim Ellison wrote:
> > >
> > >> Another attempt to resolve the threadlib mismatch problem between
> > >> classlib and VM <g>  Apologies to those who have been round this
loop
> > >> multiple times already.
> > >>
> > >> The original intent of the hythr.dll was to provide a thread library
> > >> that was shared between the VM and class library code.  But as we know,
> > >> all too painfully, we haven't seen that work too well; mainly I would
> > >> say because each VM has a close interest in the thread functionality.
> > >>
> > >> The class library needs to use the threading functions, but the contract
> > >> between classlib and threading is a bit simpler than that between the VM
> > >> and threading.
> > >>
> > >> So the proposal on the table is to discover the APIs that the classlib
> > >> needs, and add them to a new function table in the VMI struct.  That
> > >> would then put the onus on the VM to implement the thread functions.
> > >>
> > >> We may choose to keep the existing threadlib code around as a reference
> > >> for VMs that want to use it, and possibly so that the new class library
> > >> native tests have something to use, but 'in production' the classlibs
> > >> would be expected to use the same thread library code as the VM.
> > >
> > > I'd be worried about the implications on testing.  It would be nice if
> > > users could easily use their implementation as part of the native tests.
> >
> > Sure -- I didn't mean to imply that that the classlib native tests would
> > only work against this 'reference' threadlib.
> >
> > If the tests (i.e. just the new portlib native tests today) are built
> > against a particular VMs threadlib then they would use that one.
> > Keeping the current classlib impl of threadlib would mean that you
> > didn't have to choose any particular VM's threadlib to run the tests,
> > but maybe it's ok to do that, and we just delete the current one in
> > classlib.
> >
> > >> This means that the VMI would have:
> > >>   - GetPortLibrary(...) = gets portlib function table
> > >>   - GetVMLSFunctions(...) = gets VM local storage functions
> > >>   - GetThreadLibrary(...) = get thread library function table  *new*
> > >>   - all the other dross...
> > >>
> > >> I'm aware that extending the VMI makes it that much more difficult for
> > >> new VMs to play with the Harmony class library code, but in this case it
> > >> seems that trying to provide the threadlib is not solving the right
> > >> problem.
> > >
> > > Why do you say it's that much more difficult?  Don't they have to
> > > implement this anyway?
> >
> > Each extension to the VMI means that VM writers have more work to do, so
> > we should endeavour to minimize that API.  If we could share the
> > classlib threadlib impl then again, less work all round; but in this
> > case I have become convinced that the VM wants to retain control, and
> > the classlib can call into it.
> >
> > Regards,
> > Tim
> >
>

Mime
View raw message