Return-Path: 
 <harmony-dev-return-14616-apmail-incubator-harmony-dev-archive=incubator.apache.org@incubator.apache.org>
Delivered-To: apmail-incubator-harmony-dev-archive@www.apache.org
Received: (qmail 72489 invoked from network); 28 Sep 2006 14:31:17 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur.apache.org with SMTP; 28 Sep 2006 14:31:16 -0000
Received: (qmail 20748 invoked by uid 500); 28 Sep 2006 14:31:00 -0000
Delivered-To: apmail-incubator-harmony-dev-archive@incubator.apache.org
Received: (qmail 20656 invoked by uid 500); 28 Sep 2006 14:31:00 -0000
Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:harmony-dev-help@incubator.apache.org>
List-Unsubscribe: <mailto:harmony-dev-unsubscribe@incubator.apache.org>
List-Post: <mailto:harmony-dev@incubator.apache.org>
List-Id: <harmony-dev.incubator.apache.org>
Reply-To: harmony-dev@incubator.apache.org
Delivered-To: mailing list harmony-dev@incubator.apache.org
Received: (qmail 20626 invoked by uid 99); 28 Sep 2006 14:31:00 -0000
Received: from idunn.apache.osuosl.org (HELO idunn.apache.osuosl.org)
 (140.211.166.84)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 28 Sep 2006 07:31:00 -0700
Authentication-Results: idunn.apache.osuosl.org
 header.from=a.y.chernyshev@gmail.com; domainkeys=good
X-ASF-Spam-Status: No, hits=0.5 required=5.0 tests=DNS_FROM_RFC_ABUSE
DomainKey-Status: good
X-DomainKeys: Ecelerity dk_validate implementing
 draft-delany-domainkeys-base-01
Received: from [64.233.184.229] ([64.233.184.229:43618]
 helo=wr-out-0506.google.com)
	by idunn.apache.osuosl.org (ecelerity 2.1.1.8 r(12930)) with ESMTP
	id 87/21-17533-99CDB154 for <harmony-dev@incubator.apache.org>;
 Thu, 28 Sep 2006 07:30:51 -0700
Received: by wr-out-0506.google.com with SMTP id 58so184615wri
        for <harmony-dev@incubator.apache.org>;
 Thu, 28 Sep 2006 07:30:49 -0700 (PDT)
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=MPlcJJdkQKmeRUbKfSsj++RewIUEsTQ499dlhFtAz8aNgWWUsUoA0V+Z/XAbiUyGrESMAUSgNfVuLRXRs5ebG62r9KbreUz7OseN8SWb8R2Vzyk2cJhJf/UKK1MgnaVKO7liG1v8MNaNTpuW++aiVWSWbhhWtgNd5QS7o32cXC0=
Received: by 10.90.66.9 with SMTP id o9mr795648aga;
        Thu, 28 Sep 2006 07:30:48 -0700 (PDT)
Received: by 10.90.56.8 with HTTP; Thu, 28 Sep 2006 07:30:48 -0700 (PDT)
Message-ID: <6928c5160609280730g44b71a61nbcd1f4a8a6fed43a@mail.gmail.com>
Date: Thu, 28 Sep 2006 18:30:48 +0400
From: "Andrey Chernyshev" <a.y.chernyshev@gmail.com>
To: harmony-dev@incubator.apache.org
Subject: Re: [drlvm][classlib] thread library - let there be one!
In-Reply-To: <DAB56E60-9C2E-4D21-83A7-4759F607201D@pobox.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>
	 <187bb05d0609190757qecefcfaq2cd8302b2b1359b5@mail.gmail.com>
	 <45112F2E.8080201@gmail.com>
	 <4dd1f3f00609200822t2e5e2009x6e6f946843389d17@mail.gmail.com>
	 <45190A7E.1070807@gmail.com>
	 <C8451DE7-50AE-4DEE-9EC7-D1A33F011654@pobox.com>
	 <6928c5160609260729qa239d6bp1d3d9325f3b7101b@mail.gmail.com>
	 <45195AD9.1030304@gmail.com>
	 <4dd1f3f00609270831h3607714co15753810991dd0a@mail.gmail.com>
	 <DAB56E60-9C2E-4D21-83A7-4759F607201D@pobox.com>
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N

On 9/28/06, Geir Magnusson Jr. <geir@pobox.com> wrote:
>
> On Sep 27, 2006, at 11:31 AM, Weldon Washburn wrote:
>
> > +1 on the below.
> >
> > I am assuming Andrey and his team will do this work.  (Andrey, when
> > will you
> > start?)
>
> We have to start first by pulling hythread out, but where?  After
> thinking about it for 5 more seconds, putting it on the top level
>
>    enhanced/<something>
>
> is IMO a bad idea.  There's nothing worse than going to a project's
> SVN and finding tons of confusing things.

I agree making "thread" a standalone component at the level of
enhanced/<something> probably isn't worth doing. What may make a sense
is to consider thread a part of the portlib and make the portlib a
separate component at that level. Portlib is the only piece which is
shared between VM and classlib, this could justify it's appearance at
the high level.

>
> Is there any downside to keeping it somewhere under /classlib/trunk

My only guess would be the inability to build VM independently from
the classlib.

> and simply make it a module by itself?

If we can not have a portlib as a high level component (like classlib
or drlvm), then at least having it as a separate module within
classlib would be nice.

Thanks,
Andrey.

>
> >
> > Hopefully we can clean up how drlvm handles the classlib portlib
> > function
> > table at the same time.  Currently two versions of this table are
> > created
> > during startup.  "Portlib function table - let there be one!"
> > Seriously,
> > this is incredibly difficult code to maintain.
> >
> >
> > On 9/26/06, Tim Ellison <t.p.ellison@gmail.com> wrote:
> >>
> >> Yes, exactly.
> >>
> >> Regards,
> >> Tim
> >>
> >> Andrey Chernyshev wrote:
> >> > On 9/26/06, Geir Magnusson Jr. <geir@pobox.com> wrote:
> >> >> On Sep 26, 2006, at 7:09 AM, Tim Ellison wrote:
> >> >>
> >> >> > Weldon, I agree with your comments and observations below.
> >> Let's
> >> take
> >> >> > baby steps to get fully unified.  I'm sure we all want to
> >> keep things
> >> >> > working throughout.
> >> >>
> >> >> So what's the first stop?  Move hythread as-is out of classlib
> >> to a
> >> >> peer in the tree?
> >> >
> >> > I can suggest the following steps:
> >> > -  pull out hythread from classlib, make it a shared component
> >> > -  split hythread, refine the bottom layer (thrdsup.h and
> >> mutex.h) and
> >> > upper layer (hythead_xxx)
> >> > -  migrate classlib code to the bottom layer (1) of hythread
> >> > -  migrate DRLVM's thread manager to (1) from APR
> >> > Each step can be done without breaking the whole code stack.
> >> > As a result, we'll have a bottom part of hythread which will be
> >> shared
> >> > between the classlib and DRLVM.
> >> >
> >> > Some additional steps could be:
> >> > -  pull the rest of the portlib out of the classlib, make it a
> >> shared
> >> > component as well
> >> > -  migrate DRLVM to portlib
> >> >
> >> > Thanks,
> >> > Andrey.
> >> >
> >> >
> >> >>
> >> >> geir
> >> >>
> >> >> >
> >> >> > Regards,
> >> >> > Tim
> >> >> >
> >> >> > Weldon Washburn wrote:
> >> >> >> On 9/20/06, Tim Ellison <t.p.ellison@gmail.com> wrote:
> >> >> >>>
> >> >> >>> Artem Aliev wrote:
> >> >> >>>> Gier,
> >> >> >>>>
> >> >> >>>> The hythread is just most visible example. There are also
> >> signal
> >> >> >>>> handling problem. classlib hysig lib setup signal handlers
> >> and
> >> then
> >> >> >>>> drlvm overrides them by its owns. There are code
> >> duplication in
> >> >> >>>> classlib hyprt.dll drlvm port.lib:
> >> >> >>>> classlib/trunk/modules/luni/src/main/native/port vm/port/src
> >> >> >>>>
> >> >> >>>> These three pair of components contains significant part
> >> of the
> >> >> >>>> system dependent code for both VM and CLASSLIB. I think,
> >> all this
> >> >> >>>> code naturally defines portlib component that could be shared
> >> >> >>>> between
> >> >> >>>> classlib and VMs. So, as a first step, we could move all this
> >> >> >>>> code in
> >> >> >>>> to the one place, name portlib to have three directories
> >> classlib,
> >> >> >>>> drlvm, portlib.
> >> >> >>>
> >> >> >>> I think it is quite reasonable to call out the portlib and
> >> threadlib
> >> >> >>> separate (in the repository) to the VM and classlib.  As you
> >> >> >>> point out,
> >> >> >>> then VM and classlib can share the code -- though it will not
> >> >> >>> become a
> >> >> >>> requirement for VMs that run the harmony code to be using
> >> those
> >> >> >>> libraries for their own implementation.
> >> >> >>
> >> >> >>
> >> >> >> Tim,
> >> >> >> One of the things to worry about is system-wide lock
> >> protocol.  We
> >> >> >> will
> >> >> >> need
> >> >> >> to think through what locks portlib, threadlib and JVM are
> >> holding
> >> >> >> and if
> >> >> >> there are any deadlock possibilities.
> >> >> >>
> >> >> >> Another issue is the implementation of signal chaining.  There
> >> >> >> seems to be
> >> >> >> code in hysignal.c that implement "-Xrs".  I guess the idea
> >> is that
> >> a
> >> >> >> Harmony JVM would somehow not link this code and use its own
> >> >> >> implementation.  The bottom line is that we probably need to
> >> >> >> carefully pick
> >> >> >> through what is currently in classlib threads/signals and
> >> rearrange
> >> >> >> stuff so
> >> >> >> that it reduces the confusion.  We need to make this part of
> >> the
> >> >> >> system
> >> >> >> much
> >> >> >> easier to work on.
> >> >> >>
> >> >> >> Do you have recommendations on next steps?  Does it make
> >> sense to
> >> >> >> start
> >> >> >> moving stuff into the directories described above.  Or is more
> >> >> >> discussion
> >> >> >> needed.
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>> As the second step, the pairs of libraries should be merged
> >> and the
> >> >> >>>> classlib and drlvm refactoried to have only 3 lib instead
> >> of 6.
> >> >> >>>
> >> >> >>> Yep, this would be part of the consolidation into new
> >> Harmony top-
> >> >> >>> level
> >> >> >>> components.  It makes sense that we share the same impl in the
> >> >> >>> project.
> >> >> >>>
> >> >> >>>> The 3rd step is to replace most of the functions with APR
> >> ones and
> >> >> >>>> move the rest of the code to the APR.
> >> >> >>>
> >> >> >>> I think it is quite well documented on this list that this
> >> should
> >> >> >>> not be
> >> >> >>> a goal.
> >> >> >>
> >> >> >>
> >> >> >> I agree we don't need to move classlib to APR provided that:
> >> >> >>
> >> >> >> 1)
> >> >> >> There is an easy to understand distinct seperation of the
> >> different
> >> >> >> threading/signals packages.  In specific, we need to know which
> >> >> >> threading
> >> >> >> package is being called by DRLVM without ambiguity.
> >> >> >>
> >> >> >> 2)
> >> >> >> There is clear understanding of how JVM and classlib threading/
> >> >> >> signals
> >> >> >> interoperate.
> >> >> >>
> >> >> >>
> >> >> >> Regards,
> >> >> >>> Tim
> >> >> >>>
> >> >> >>>> Thoughts?
> >> >> >>>>
> >> >> >>>> Thanks
> >> >> >>>> Artem
> >> >> >>>>
> >> >> >>>>
> >> >> >>>>
> >> >> >>>>
> >> >> >>>>
> >> >> >>>>
> >> >> >>>> On 9/19/06, Geir Magnusson Jr. <geir@pobox.com> wrote:
> >> >> >>>>> All,
> >> >> >>>>>
> >> >> >>>>> we need to put this issue to bed, as we're tripping over
> >> it, it
> >> >> >>>>> seems.
> >> >> >>>>>
> >> >> >>>>> Any thoughts on how to move forward on this?
> >> >> >>>>>
> >> >> >>>>> geir
> >> >> >>>>>
> >> >> >>>>>
> >> >> >>>>>
> >> ------------------------------------------------------------------
> >> >> >>>>> ---
> >> >> >>>>> Terms of use : http://incubator.apache.org/harmony/
> >> mailing.html
> >> >> >>>>> To unsubscribe, e-mail: harmony-dev-
> >> >> >>>>> unsubscribe@incubator.apache.org
> >> >> >>>>> For additional commands, e-mail: harmony-dev-
> >> >> >>>>> help@incubator.apache.org
> >> >> >>>>>
> >> >> >>>>>
> >> >> >>>>
> >> >> >>>>
> >> -------------------------------------------------------------------
> >> >> >>>> --
> >> >> >>>> Terms of use : http://incubator.apache.org/harmony/
> >> mailing.html
> >> >> >>>> To unsubscribe, e-mail: harmony-dev-
> >> >> >>>> unsubscribe@incubator.apache.org
> >> >> >>>> For additional commands, e-mail: harmony-dev-
> >> >> >>>> help@incubator.apache.org
> >> >> >>>>
> >> >> >>>>
> >> >> >>>
> >> >> >>> --
> >> >> >>>
> >> >> >>> Tim Ellison (t.p.ellison@gmail.com)
> >> >> >>> IBM Java technology centre, UK.
> >> >> >>>
> >> >> >>>
> >> --------------------------------------------------------------------
> >> >> >>> -
> >> >> >>> Terms of use : http://incubator.apache.org/harmony/
> >> mailing.html
> >> >> >>> To unsubscribe, e-mail:
> >> harmony-dev-unsubscribe@incubator.apache.org
> >> >> >>> For additional commands, e-mail: harmony-dev-
> >> >> >>> help@incubator.apache.org
> >> >> >>>
> >> >> >>>
> >> >> >>
> >> >> >>
> >> >> >
> >> >> > --
> >> >> >
> >> >> > Tim Ellison (t.p.ellison@gmail.com)
> >> >> > IBM Java technology centre, UK.
> >> >> >
> >> >> >
> >> ---------------------------------------------------------------------
> >> >> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> >> >> > To unsubscribe, e-mail: harmony-dev-
> >> unsubscribe@incubator.apache.org
> >> >> > For additional commands, e-mail:
> >> harmony-dev-help@incubator.apache.org
> >> >> >
> >> >>
> >> >>
> >> >>
> >> ---------------------------------------------------------------------
> >> >> Terms of use : http://incubator.apache.org/harmony/mailing.html
> >> >> To unsubscribe, e-mail: harmony-dev-
> >> unsubscribe@incubator.apache.org
> >> >> For additional commands, e-mail: harmony-dev-
> >> help@incubator.apache.org
> >> >>
> >> >>
> >> >
> >> >
> >>
> >> --
> >>
> >> Tim Ellison (t.p.ellison@gmail.com)
> >> IBM Java technology centre, UK.
> >>
> >> ---------------------------------------------------------------------
> >> Terms of use : http://incubator.apache.org/harmony/mailing.html
> >> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> >> For additional commands, e-mail: harmony-dev-
> >> help@incubator.apache.org
> >>
> >>
> >
> >
> > --
> > Weldon Washburn
> > Intel Middleware Products Division
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>


-- 
Andrey Chernyshev
Intel Middleware Products Division

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org