harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject Re: [drlvm][classlib] thread library - let there be one!
Date Sun, 15 Oct 2006 18:53:02 GMT
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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message