First step (moving out of luni) looks good to me. I'd like some more discussion around the second step (picking up drlvm version) before you do a wholesale replacement.
Regards, Tim Weldon Washburn wrote: > Artem, > Thanks. I will take a look. > > > On 10/12/06, Artem Aliev <[EMAIL PROTECTED]> wrote: >> >> 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 <[EMAIL PROTECTED]> 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. <[EMAIL PROTECTED]> wrote: >> > > >> > > On Sep 28, 2006, at 10:30 AM, Andrey Chernyshev wrote: >> > > >> > > > On 9/28/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> 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. >> > > >> > > 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 <[EMAIL PROTECTED]> wrote: >> > > >> >> >> > > >> >> Yes, exactly. >> > > >> >> >> > > >> >> Regards, >> > > >> >> Tim >> > > >> >> >> > > >> >> Andrey Chernyshev wrote: >> > > >> >> > On 9/26/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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. <[EMAIL PROTECTED]> 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- >> > > >> >> >> >>>>> [EMAIL PROTECTED] >> > > >> >> >> >>>>> For additional commands, e-mail: harmony-dev- >> > > >> >> >> >>>>> [EMAIL PROTECTED] >> > > >> >> >> >>>>> >> > > >> >> >> >>>>> >> > > >> >> >> >>>> >> > > >> >> >> >>>> >> > > >> >> >> > > >> >> ------------------------------------------------------------------- >> > > >> >> >> >>>> -- >> > > >> >> >> >>>> Terms of use : http://incubator.apache.org/harmony/ >> > > >> >> mailing.html >> > > >> >> >> >>>> To unsubscribe, e-mail: harmony-dev- >> > > >> >> >> >>>> [EMAIL PROTECTED] >> > > >> >> >> >>>> For additional commands, e-mail: harmony-dev- >> > > >> >> >> >>>> [EMAIL PROTECTED] >> > > >> >> >> >>>> >> > > >> >> >> >>>> >> > > >> >> >> >>> >> > > >> >> >> >>> -- >> > > >> >> >> >>> >> > > >> >> >> >>> Tim Ellison ([EMAIL PROTECTED]) >> > > >> >> >> >>> IBM Java technology centre, UK. >> > > >> >> >> >>> >> > > >> >> >> >>> >> > > >> >> >> > > >> >> -------------------------------------------------------------------- >> > > >> >> >> >>> - >> > > >> >> >> >>> Terms of use : http://incubator.apache.org/harmony/ >> > > >> >> mailing.html >> > > >> >> >> >>> To unsubscribe, e-mail: >> > > >> >> [EMAIL PROTECTED] >> > > >> >> >> >>> For additional commands, e-mail: harmony-dev- >> > > >> >> >> >>> [EMAIL PROTECTED] >> > > >> >> >> >>> >> > > >> >> >> >>> >> > > >> >> >> >> >> > > >> >> >> >> >> > > >> >> >> > >> > > >> >> >> > -- >> > > >> >> >> > >> > > >> >> >> > Tim Ellison ([EMAIL PROTECTED]) >> > > >> >> >> > IBM Java technology centre, UK. >> > > >> >> >> > >> > > >> >> >> > >> > > >> >> >> > > >> >> --------------------------------------------------------------------- >> > > >> >> >> > Terms of use : http://incubator.apache.org/harmony/ >> > > >> mailing.html >> > > >> >> >> > To unsubscribe, e-mail: harmony-dev- >> > > >> >> [EMAIL PROTECTED] >> > > >> >> >> > For additional commands, e-mail: >> > > >> >> [EMAIL PROTECTED] >> > > >> >> >> > >> > > >> >> >> >> > > >> >> >> >> > > >> >> >> >> > > >> >> >> > > >> >> --------------------------------------------------------------------- >> > > >> >> >> Terms of use : >> http://incubator.apache.org/harmony/mailing.html >> > > >> >> >> To unsubscribe, e-mail: harmony-dev- >> > > >> >> [EMAIL PROTECTED] >> > > >> >> >> For additional commands, e-mail: harmony-dev- >> > > >> >> [EMAIL PROTECTED] >> > > >> >> >> >> > > >> >> >> >> > > >> >> > >> > > >> >> > >> > > >> >> >> > > >> >> -- >> > > >> >> >> > > >> >> Tim Ellison ([EMAIL PROTECTED]) >> > > >> >> IBM Java technology centre, UK. >> > > >> >> >> > > >> >> >> > > >> >> --------------------------------------------------------------------- >> > > >> >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> > > >> >> To unsubscribe, e-mail: harmony-dev- >> > > >> [EMAIL PROTECTED] >> > > >> >> For additional commands, e-mail: harmony-dev- >> > > >> >> [EMAIL PROTECTED] >> > > >> >> >> > > >> >> >> > > >> > >> > > >> > >> > > >> > -- >> > > >> > Weldon Washburn >> > > >> > Intel Middleware Products Division >> > > >> >> > > >> >> > > >> >> --------------------------------------------------------------------- >> > > >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> > > >> To unsubscribe, e-mail: >> [EMAIL PROTECTED] >> > > >> For additional commands, e-mail: harmony-dev- >> > > >> [EMAIL PROTECTED] >> > > >> >> > > >> >> > > > >> > > > >> > > > -- >> > > > Andrey Chernyshev >> > > > Intel Middleware Products Division >> > > > >> > > > >> --------------------------------------------------------------------- >> > > > Terms of use : http://incubator.apache.org/harmony/mailing.html >> > > > To unsubscribe, e-mail: >> [EMAIL PROTECTED] >> > > > For additional commands, e-mail: >> [EMAIL PROTECTED] >> > > > >> > > >> > > >> > > --------------------------------------------------------------------- >> > > Terms of use : http://incubator.apache.org/harmony/mailing.html >> > > To unsubscribe, e-mail: [EMAIL PROTECTED] >> > > For additional commands, e-mail: >> [EMAIL PROTECTED] >> > > >> > > >> > >> >> --------------------------------------------------------------------- >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
