harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: [drlvm][classlib] thread library - let there be one!
Date Thu, 28 Sep 2006 14:41:09 GMT

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


Mime
View raw message