harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Hindess <mark.hind...@googlemail.com>
Subject Re: [drlvm][classlib] thread library - let there be one!
Date Sun, 15 Oct 2006 20:55:33 GMT

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" <weldonwjw@gmail.com> wrote:
> 
> Artem,
> Thanks.  I will take a look.
> 
> 
> On 10/12/06, Artem Aliev <artem.aliev@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 <artem.aliev@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. <geir@pobox.com> wrote:
> > > >
> > > > On Sep 28, 2006, at 10:30 AM, Andrey Chernyshev wrote:
> > > >
> > > > > On 9/28/06, Geir Magnusson Jr. <geir@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.p.ellison@gmail.com> wrote:
> > > > >> >>
> > > > >> >> 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
> > > > >> >>
> > > > >> >>
> > > > >> >
> > > > >> >
> > > > >> > --
> > > > >> > 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


Mime
View raw message