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