Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (herse.apache.org: domain of alin.harmony@gmail.com
 designates 64.233.184.239 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=sbG6ZWbd/I+4Jm9IEwYMZfWXSAJK5BXGSMEOasWiPaxdnNWmRByECjSwQtuUpp9EBmqXc1TMrbl4EiiXPDyK9M5Ok1grld+gz4wp7JYIFbDuM0PI2hcuupiqU+fWT1qWXkkt2Iz3t2+oUkL9cTSc1F8E9O+ahlwdoE4iuKCQlKA=
Message-ID: <3ae04f990610260745u7ea18e27k35c5825c2c2fda1@mail.gmail.com>
Date: Thu, 26 Oct 2006 10:45:35 -0400
From: "Angela Lin" <alin.harmony@gmail.com>
To: harmony-dev@incubator.apache.org
Subject: Re: [drlvm][classlib] thread library - let there be one!
In-Reply-To: <4dd1f3f00610241447i3f0ce6d2h7d2ad75382be7334@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <E241463B-8FE8-41CC-80D2-5536CCCE37EC@pobox.com>
	 <45338A06.6060907@gmail.com> <4533915B.8030201@pobox.com>
	 <187bb05d0610160721j3ad43530l8a7a9857e9da5939@mail.gmail.com>
	 <3ae04f990610171457x473b9613o3025847aed134710@mail.gmail.com>
	 <187bb05d0610190804o611fdbd0u9d064e752545408@mail.gmail.com>
	 <3ae04f990610231045s3aa4c0ddg2452d477879566e1@mail.gmail.com>
	 <4dd1f3f00610240432v51f2d531obebdd5a9ef6f1789@mail.gmail.com>
	 <3ae04f990610240934r4b2b6266o9f998455829e8550@mail.gmail.com>
	 <4dd1f3f00610241447i3f0ce6d2h7d2ad75382be7334@mail.gmail.com>

On 10/24/06, Weldon Washburn <weldonwjw@gmail.com> wrote:
>
> If an arbitrary commercial JVM decided to use classlib, will it need to be
> modified to reflect the existing Harmony Classlib threading model?

This is the case no matter how you split the thread library. Whatever
interface you specify for the classlib will need to be supported by
the VM.

> Also, does this mean VM design is constrained by classlib design?  And
> classlib  design is constrained by J9 design?

The classlib and the VM have certain dependencies on each other. This
is not a J9-specific issue.

I would aim for a thread API that is generic enough to support
multiple implementations.

Mature VMs that switch to the Harmony classlib would probably
implement a portability layer between the existing VM's thread model
and the Harmony thread API.

Has anyone considered how ThreadMXBean would be supported by the
proposed classlib thread API subset?

> On 10/24/06, Angela Lin <alin.harmony@gmail.com> wrote:
> >
> > Consider the group of monitor-related functionality: enter/exit,
> > wait/notify, and interrupt. The implementations of these functions are
> > closely related in the J9-derived hythread, particularly for 3-tier
> > locking. We need to coordinate when we lock the thread mutex, when we
> > lock the monitor mutex, how we use spinlocks, etc. It would be
> > unnatural to split out enter/exit from this group.
>
>
> >
> > On 10/24/06, Weldon Washburn <weldonwjw@gmail.com> wrote:
> > > On 10/23/06, Angela Lin <alin.harmony@gmail.com> wrote:
> > > >
> > > > What is the goal here?
> > > >
> > > > 1. If the goal is to create a single thread library that can be used
> > > > by multiple VM and classlib implementations, then the unified thread
> > > > lib should contain everything needed to support a VM implementation.
> > > >
> > > > 2. If the goal is to simply define the interface between the classlib
> > > > and the VM, then the 3rd option may be acceptable. This option seems
> > > > to imply splitting up functionality that requires deep knowledge of
> > > > the threading implementation, which I don't like. Each VM
> > > > implementation would need to implement both the VM and classlib sides
> > > > of the API.
> > >
> > > Is this really the situation?  If Classlib only needs monenter/exit, TLS
> > and
> > > thread_create(), the "deep knowledge" required is probably only
> > > monitorenter/exit which seems like a managable situation.
> > >
> > >
> > > Regards,
> > > > Angela
> > > >
> > > > On 10/19/06, Artem Aliev <artem.aliev@gmail.com> wrote:
> > > > > Angela, all,
> > > > >
> > > > > I see you point and agree.
> > > > > But if we move hythread lib to the VM we will require all VMs fully
> > > > support it.
> > > > > Is it necessary dependency?
> > > > >
> > > > > So Here is the third way I see.
> > > > > Leave the minimum implementation of hythread in the classlib, with
> > the
> > > > > set of functions any VM should provide for classlib.
> > > > >   This will simplifies adopting classlib to new VM and allows to
> > have
> > > > > solid threading model.
> > > > > So any VM could have its own super set of threading functions.
> > > > >
> > > > > Note: Classlib uses only monitor, TLS, and thread_create() from
> > > > hythread.
> > > > >
> > > > > Thanks
> > > > > Artem
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On 10/18/06, Angela Lin <alin.harmony@gmail.com> wrote:
> > > > > > Artem et al,
> > > > > >
> > > > > > Sorry for jumping in late here.
> > > > > >
> > > > > > I maintain the J9VM thread lib.
> > > > > >
> > > > > > Option 1 worries me because it implies that the classlib could use
> > a
> > > > > > different threading model from the VM. This is bad because they
> > both
> > > > > > operate on the same threads.
> > > > > >
> > > > > > For example: Layer (2) of hythread might include internal thread
> > state
> > > > > > tracking, which is needed to support inspecting the thread state.
> > > > > > Using layer (1) directly would bypass the thread state tracking.
> > > > > >
> > > > > > Angela
> > > > > >
> > > >
> > >
> > >
> >
>
>
>
> --
> Weldon Washburn
> Intel Middleware Products Division
>
>