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: [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]
