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 Thu, 28 Sep 2006 14:30:48 GMT
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.

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

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


Mime
View raw message