harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [drlvm][classlib] thread library - let there be one!
Date Mon, 16 Oct 2006 13:32:54 GMT
First step (moving out of luni) looks good to me.

I'd like some more discussion around the second step (picking up drlvm
version) before you do a wholesale replacement.

Regards,
Tim

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

-- 

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


Mime
View raw message