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