+1 on the below. I am assuming Andrey and his team will do this work. (Andrey, when will you start?)
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: [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]
-- Weldon Washburn Intel Middleware Products Division
