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 Tue, 26 Sep 2006 11:09:50 GMT
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.

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


Mime
View raw message