harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrey Chernyshev" <a.y.chernys...@gmail.com>
Subject Re: [drlvm][classlib] thread library - let there be one!
Date Tue, 26 Sep 2006 14:29:38 GMT
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
>
>


-- 
Andrey Chernyshev
Intel Middleware Products Division

---------------------------------------------------------------------
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