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 04:33:53 GMT

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.

Is there any downside to keeping it somewhere under /classlib/trunk  
and simply make it a module by itself?

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


Mime
View raw message