harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [drlvm][classlib] thread library - let there be one!
Date Tue, 26 Sep 2006 16:52:41 GMT
Yes, exactly.

Regards,
Tim

Andrey Chernyshev wrote:
> On 9/26/06, Geir Magnusson Jr. <geir@pobox.com> 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 <t.p.ellison@gmail.com> 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. <geir@pobox.com> 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-
>> >>>>> unsubscribe@incubator.apache.org
>> >>>>> For additional commands, e-mail: harmony-dev-
>> >>>>> help@incubator.apache.org
>> >>>>>
>> >>>>>
>> >>>>
>> >>>> -------------------------------------------------------------------
>> >>>> --
>> >>>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> >>>> To unsubscribe, e-mail: harmony-dev-
>> >>>> unsubscribe@incubator.apache.org
>> >>>> For additional commands, e-mail: harmony-dev-
>> >>>> help@incubator.apache.org
>> >>>>
>> >>>>
>> >>>
>> >>> --
>> >>>
>> >>> Tim Ellison (t.p.ellison@gmail.com)
>> >>> IBM Java technology centre, UK.
>> >>>
>> >>> --------------------------------------------------------------------
>> >>> -
>> >>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> >>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> >>> For additional commands, e-mail: harmony-dev-
>> >>> help@incubator.apache.org
>> >>>
>> >>>
>> >>
>> >>
>> >
>> > --
>> >
>> > Tim Ellison (t.p.ellison@gmail.com)
>> > IBM Java technology centre, UK.
>> >
>> > ---------------------------------------------------------------------
>> > Terms of use : http://incubator.apache.org/harmony/mailing.html
>> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>> >
>>
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>>
> 
> 

-- 

Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message