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 Tue, 26 Sep 2006 13:13:16 GMT

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?

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


Mime
View raw message