You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Mark Hindess <ma...@googlemail.com> on 2006/10/15 22:55:33 UTC
Re: [drlvm][classlib] thread library - let there be one!
Artem,
Thanks for this patch. Works for me on Linux.
Moving common and pool as well seems reasonable.
I'll make a minor modification once Weldon has committed it. (Just to
combine the copy-native-includes-windows and copy-native-includes-linux
actions into a second copy in the copy-native-includes target by using
the ${hy.os} variable as the last component in the path.)
Regards,
Mark.
On 15 October 2006 at 11:53, "Weldon Washburn" <we...@gmail.com> wrote:
>
> Artem,
> Thanks. I will take a look.
>
>
> On 10/12/06, Artem Aliev <ar...@gmail.com> wrote:
> >
> > Guys,
> >
> >
> > > 1. Make classlib/modules/portlib directory (or portlib in the root?)
> > > and move hyprt, hysig and hythread code into it. Update build to work
> > > with new directory.
> > >
> > > > [Andrey]- pull out hythread from classlib, make it a shared component
> > >
> >
> > The first step is done in JIRA HARMONY-1843.
> >
> > I move common, pool, port, thread, sig from luni to new component portlib.
> > The first idea was to move only port, thread, sig, but they depend on
> > common and pool libs. It looks natural to do not produce cyclic
> > dependencies among components, so I move these two also to portlib.
> >
> > Unfortunately, this does not fully solve two stage luni building
> > process (build-native-core and build-native-secondary), but this is
> > another problem.
> >
> > So If we are still committed on these reorganization, please review
> > and apply the patch.
> >
> > A move_to_portlib.sh script create portlib directory structure and
> > move appropriate files from luni to portlib (by svn move).
> > A portlib_files.patch update build to works with new structure.
> >
> > Thanks
> > Artem
> >
> >
> >
> >
> > On 9/29/06, Artem Aliev <ar...@gmail.com> wrote:
> > > Guys,
> > >
> > > Let me try to make this changes.
> > >
> > > Here is my understanding of the steps I need to do.
> > >
> > > 1. Make classlib/modules/portlib directory (or portlib in the root?)
> > > and move hyprt, hysig and hythread code into it. Update build to work
> > > with new directory.
> > >
> > > > [Andrey]- pull out hythread from classlib, make it a shared component
> > >
> > > 2. Move DRLVM hythread to classlib and update drlvm build for it. So
> > > both classlib and drlvm will work on the drlvm hythread.
> > >
> > > > - 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
> > > I do not think it is necessary because the hythread will be shared
> > library.
> > > This make sense only in case we move only layer(1) into the shared
> > directory.
> > >
> > > 3. merge hythreads into one library getting bast code from both sources.
> > > > migrate DRLVM's thread manager to (1) from APR
> > > Will be done on this stage.
> > >
> > > 4. merge classlib and drlvm signal handling code.
> > >
> > > 5. merge port libs code.
> > >
> > > 6. ????
> > >
> > > Thanks
> > > Artem
> > >
> > > On 9/28/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> > > >
> > > > On Sep 28, 2006, at 10:30 AM, Andrey Chernyshev wrote:
> > > >
> > > > > On 9/28/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> > > > >>
> > > > >> On Sep 27, 2006, at 11:31 AM, Weldon Washburn wrote:
> > > > >>
> > > > >> > +1 on the below.
> > > > >> >
> > > > >> > I am assuming Andrey and his team will do this work. (Andrey,
> > when
> > > > >> > will you
> > > > >> > start?)
> > > > >>
> > > > >> We have to start first by pulling hythread out, but where? After
> > > > >> thinking about it for 5 more seconds, putting it on the top level
> > > > >>
> > > > >> enhanced/<something>
> > > > >>
> > > > >> is IMO a bad idea. There's nothing worse than going to a project's
> > > > >> SVN and finding tons of confusing things.
> > > > >
> > > > > I agree making "thread" a standalone component at the level of
> > > > > enhanced/<something> probably isn't worth doing. What may make a
> > sense
> > > > > is to consider thread a part of the portlib and make the portlib a
> > > > > separate component at that level. Portlib is the only piece which is
> > > > > shared between VM and classlib, this could justify it's appearance
> > at
> > > > > the high level.
> > > > >
> > > > >>
> > > > >> Is there any downside to keeping it somewhere under /classlib/trunk
> > > > >
> > > > > My only guess would be the inability to build VM independently from
> > > > > the classlib.
> > > >
> > > > Sure, you'll still need either to build the /portlib or the /classlib
> > > >
> > > > >
> > > > >> and simply make it a module by itself?
> > > > >
> > > > > If we can not have a portlib as a high level component (like
> > classlib
> > > > > or drlvm), then at least having it as a separate module within
> > > > > classlib would be nice.
> > > >
> > > > This is one of those things where doing the small step (do it in
> > > > classlib) and then consider the large step (do it as a peer) seems to
> > > > be reasonable, but i don't feel too strongly...
> > > >
> > > > geir
> > > >
> > > > >
> > > > > Thanks,
> > > > > Andrey.
> > > > >
> > > > >>
> > > > >> >
> > > > >> > 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 <t....@gmail.com> wrote:
> > > > >> >>
> > > > >> >> Yes, exactly.
> > > > >> >>
> > > > >> >> Regards,
> > > > >> >> Tim
> > > > >> >>
> > > > >> >> Andrey Chernyshev wrote:
> > > > >> >> > On 9/26/06, Geir Magnusson Jr. <ge...@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....@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. <ge...@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
> > > > >> >>
> > > > >> >>
> > > > >> >
> > > > >> >
> > > > >> > --
> > > > >> > Weldon Washburn
> > > > >> > 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
> > > > >>
> > > > >>
> > > > >
> > > > >
> > > > > --
> > > > > 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
> > > > >
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > 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
> >
> >
>
>
> --
> Weldon Washburn
> Intel Middleware Products Division
>
> ------=_Part_35454_4540277.1160938382328--
>
---------------------------------------------------------------------
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