>
> 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: harmony-dev-
>> [EMAIL PROTECTED]
>> >> > For additional commands, e-mail:
>> [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: harmony-dev-
[EMAIL PROTECTED]
>> For additional commands, e-mail: harmony-dev-
>> [EMAIL PROTECTED]
>>
>>
>
>
> --
> Weldon Washburn
> 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: harmony-dev-
[EMAIL PROTECTED]