Ivan Volosyuk wrote: > Looks like a matter of relations, how the classlib and VM relates to > each other. > > Either VM and classlib independant, then we need something to be > common base for them - portlib. If VM links with classlib, then no > more need for portlib, just well understood interfaces provided by > classlib's HDK. If classlib links with VM, then it is the VM who > should provide this interfaces :)
I'm unclear on your definition of 'links with', but I envisage that the portlib and threadlib become a set of utility functions that are usable and sufficient for both the DRLVM and classlib code. It certainly doesn't make sense to maintain two different versions of what is essentially the same thing. Let's look at the differences in implementation and resolve to reconcile them into a single project-wide version. Regards, Tim > On 9/19/06, Artem Aliev <[EMAIL PROTECTED]> 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. >> >> 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. >> >> The 3rd step is to replace most of the functions with APR ones and >> move the rest of the code to the APR. >> >> 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] > > -- 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]
