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]
-- Weldon Washburn Intel Middleware Products Division
