Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (idunn.apache.osuosl.org: domain gmail.com designates
 66.249.92.169 as permitted sender)
DomainKey-Status: good
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding;
        b=jb6bGtu0mdixeF50WqLCeaby4i/8wfK86DrrdsgmiZf4B9sWi2SpozF36XsaTu1ZXiAqYp8fatc/KLpnmC+GxM8YrJFkOi4/qB43CHI7XXs2Gre4QdRVOsMhtEmG0XyNNJDYklSGl5ukAFlw3Pj3p+jdFW8dmwn8Snf8uPb2oWc=
Message-ID: <45190A7E.1070807@gmail.com>
Date: Tue, 26 Sep 2006 12:09:50 +0100
From: Tim Ellison <t.p.ellison@gmail.com>
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: harmony-dev@incubator.apache.org
Subject: Re: [drlvm][classlib] thread library - let there be one!
References: <E241463B-8FE8-41CC-80D2-5536CCCE37EC@pobox.com>
	 <187bb05d0609190757qecefcfaq2cd8302b2b1359b5@mail.gmail.com>
	 <45112F2E.8080201@gmail.com>
 <4dd1f3f00609200822t2e5e2009x6e6f946843389d17@mail.gmail.com>
In-Reply-To: <4dd1f3f00609200822t2e5e2009x6e6f946843389d17@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

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