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