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