Return-Path: Delivered-To: apmail-incubator-harmony-dev-archive@www.apache.org Received: (qmail 32134 invoked from network); 12 Oct 2006 11:05:56 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 12 Oct 2006 11:05:56 -0000 Received: (qmail 47225 invoked by uid 500); 12 Oct 2006 11:05:53 -0000 Delivered-To: apmail-incubator-harmony-dev-archive@incubator.apache.org Received: (qmail 47053 invoked by uid 500); 12 Oct 2006 11:05:52 -0000 Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: harmony-dev@incubator.apache.org Delivered-To: mailing list harmony-dev@incubator.apache.org Received: (qmail 47042 invoked by uid 99); 12 Oct 2006 11:05:52 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 12 Oct 2006 04:05:52 -0700 X-ASF-Spam-Status: No, hits=0.5 required=10.0 tests=DNS_FROM_RFC_ABUSE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of artem.aliev@gmail.com designates 64.233.182.186 as permitted sender) Received: from [64.233.182.186] (HELO nf-out-0910.google.com) (64.233.182.186) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 12 Oct 2006 04:05:50 -0700 Received: by nf-out-0910.google.com with SMTP id c29so1011776nfb for ; Thu, 12 Oct 2006 04:05:29 -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=Xwbg3H21/Mk9+lvmeBw8br2U+W5Afb2SkjdRrM/JriAYhtotUolbQibHKFAQyQrpPqUg7sHkFJLq/hUv6OpXbINgU0+ETBpES/di3008DbF1WIj8PdSkAwe5Ywik0iSUW5bE8d9SWnWDoLyYkgkzSDBAeMskRHhz/Jkx02dRBCw= Received: by 10.82.118.2 with SMTP id q2mr324903buc; Thu, 12 Oct 2006 04:05:28 -0700 (PDT) Received: by 10.82.100.11 with HTTP; Thu, 12 Oct 2006 04:05:28 -0700 (PDT) Message-ID: <187bb05d0610120405p78fed77fraecc9f88d284530e@mail.gmail.com> Date: Thu, 12 Oct 2006 15:05:28 +0400 From: "Artem Aliev" To: harmony-dev@incubator.apache.org Subject: Re: [drlvm][classlib] thread library - let there be one! In-Reply-To: <187bb05d0609290701y7856e080ge2a6bd8c73f8c891@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: <45190A7E.1070807@gmail.com> <6928c5160609260729qa239d6bp1d3d9325f3b7101b@mail.gmail.com> <45195AD9.1030304@gmail.com> <4dd1f3f00609270831h3607714co15753810991dd0a@mail.gmail.com> <6928c5160609280730g44b71a61nbcd1f4a8a6fed43a@mail.gmail.com> <74BBC84D-D8F8-4498-A1DF-B48267DEA025@pobox.com> <187bb05d0609290701y7856e080ge2a6bd8c73f8c891@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Guys, > 1. Make classlib/modules/portlib directory (or portlib in the root?) > and move hyprt, hysig and hythread code into it. Update build to work > with new directory. > > > [Andrey]- pull out hythread from classlib, make it a shared component > The first step is done in JIRA HARMONY-1843. I move common, pool, port, thread, sig from luni to new component portlib. The first idea was to move only port, thread, sig, but they depend on common and pool libs. It looks natural to do not produce cyclic dependencies among components, so I move these two also to portlib. Unfortunately, this does not fully solve two stage luni building process (build-native-core and build-native-secondary), but this is another problem. So If we are still committed on these reorganization, please review and apply the patch. A move_to_portlib.sh script create portlib directory structure and move appropriate files from luni to portlib (by svn move). A portlib_files.patch update build to works with new structure. Thanks Artem On 9/29/06, Artem Aliev wrote: > Guys, > > Let me try to make this changes. > > Here is my understanding of the steps I need to do. > > 1. Make classlib/modules/portlib directory (or portlib in the root?) > and move hyprt, hysig and hythread code into it. Update build to work > with new directory. > > > [Andrey]- pull out hythread from classlib, make it a shared component > > 2. Move DRLVM hythread to classlib and update drlvm build for it. So > both classlib and drlvm will work on the drlvm hythread. > > > - 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 > I do not think it is necessary because the hythread will be shared library. > This make sense only in case we move only layer(1) into the shared directory. > > 3. merge hythreads into one library getting bast code from both sources. > > migrate DRLVM's thread manager to (1) from APR > Will be done on this stage. > > 4. merge classlib and drlvm signal handling code. > > 5. merge port libs code. > > 6. ???? > > Thanks > Artem > > On 9/28/06, Geir Magnusson Jr. wrote: > > > > On Sep 28, 2006, at 10:30 AM, Andrey Chernyshev wrote: > > > > > On 9/28/06, Geir Magnusson Jr. 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/ > > >> > > >> 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/ 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. > > > > Sure, you'll still need either to build the /portlib or 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. > > > > This is one of those things where doing the small step (do it in > > classlib) and then consider the large step (do it as a peer) seems to > > be reasonable, but i don't feel too strongly... > > > > geir > > > > > > > > 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 wrote: > > >> >> > > >> >> Yes, exactly. > > >> >> > > >> >> Regards, > > >> >> Tim > > >> >> > > >> >> Andrey Chernyshev wrote: > > >> >> > On 9/26/06, Geir Magnusson Jr. 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 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. 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 > > > > > > > > > --------------------------------------------------------------------- > > 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