Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (nike.apache.org: domain of wenlong@gmail.com designates
 74.125.92.149 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version
         :content-type:content-transfer-encoding:content-disposition
         :references;
        b=VZOs58YGamAoAmJs81I5Pw45Z22EwHLfLgHjZTKkwSrUTOljJ5uCwz5vfZOnOYzzdK
         ohe3ZD70i21JhS38SWcML1XpJb84cdSXr9AcOQSpIIJEqIHF9hv+DXeIvW1oMBzidjj9
         ObhYxBj85JGlEcQo8F9AK3AMO5tc/ig/6ya3o=
Message-ID: <bdbaeccd0812250609h2c89fb57g38ca25f7502a12f5@mail.gmail.com>
Date: Thu, 25 Dec 2008 22:09:21 +0800
From: "Wenlong Li" <wenlong@gmail.com>
To: dev@harmony.apache.org
Subject: Re: [VM] On-demand class library parsing is ready to commit
In-Reply-To: <e0f125db0812250600p5961323aofbf9c83bfd41a039@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <bdbaeccd0812182345t599e5240nba129989ada374b8@mail.gmail.com>
	 <4bebff790812250006x6a747848k6ae42957f6b04fee@mail.gmail.com>
	 <bdbaeccd0812250022q5ec90bb8r2883151dc28bc583@mail.gmail.com>
	 <4bebff790812250027k26d9075s3fb71e3dd0757950@mail.gmail.com>
	 <bdbaeccd0812250049t55d993b8n492916369a716bba@mail.gmail.com>
	 <4bebff790812250132sc3318c8g8530e6d56b9641@mail.gmail.com>
	 <bdbaeccd0812250448i5ecb416fn587035b0120e1ca@mail.gmail.com>
	 <e0f125db0812250505t5cd6eaf6qab05269537604a9c@mail.gmail.com>
	 <bdbaeccd0812250558u240e369cm2e08d460a8ad45b4@mail.gmail.com>
	 <e0f125db0812250600p5961323aofbf9c83bfd41a039@mail.gmail.com>

Sorry, one more question: bootclasspath.properties is classlib
specific file, why we could not make a vm specific file manually? Just
curious to know the possible reason. :)

thx,
Wenlong

On Thu, Dec 25, 2008 at 10:00 PM, Pavel Pervov <pmcfirst@gmail.com> wrote:
> If this would be VM-side automatically produced configuration file...
>
> WBR,
>    Pavel.
>
> On Thu, Dec 25, 2008 at 4:58 PM, Wenlong Li <wenlong@gmail.com> wrote:
>> btw, because adding new module is rare case, manually modifying the
>> bootclasspath.properties is not an issue?
>>
>> If so, can I conclude adding another property file with same update
>> frequency as bootclasspath would be fine as well?
>>
>> Pls kindly correct me if my understanding is wrong.
>>
>> On Thu, Dec 25, 2008 at 9:05 PM, Pavel Pervov <pmcfirst@gmail.com> wrote:
>>> Wenlong,
>>>
>>> Note, that bootclasspath.properties is only changed on adding new
>>> module. This is pretty rare occasion, I believe.
>>>
>>> WBR,
>>>    Pavel.
>>>
>>> On Thu, Dec 25, 2008 at 3:48 PM, Wenlong Li <wenlong@gmail.com> wrote:
>>>> Thx for your advice. Alexey.
>>>>
>>>> Here I have one question: do you know how the bootclasspath.properties
>>>> is maintained, manually or automatically?
>>>>
>>>> Another comment is I would like to treat the patch as DRLVM specific
>>>> optimization, e.g., it targets for improving VM creation time. So that
>>>> is possible to move all updates to DRLVM part to eliminate potential
>>>> modularity and compatibility problem.
>>>>
>>>> thx,
>>>> Wenlong
>>>>
>>>> On Thu, Dec 25, 2008 at 5:32 PM, Aleksey Shipilev
>>>> <aleksey.shipilev@gmail.com> wrote:
>>>>> Hi, Wenlong.
>>>>>
>>>>> On Thu, Dec 25, 2008 at 11:49 AM, Wenlong Li <wenlong@gmail.com> wrote:
>>>>>> btw, Alexey, Let's go back to discuss whether there is a need to
>>>>>> include this feature in Harmony, given 17% performance gain in Linux
>>>>>> when using your methodology. For windows test, I will double check the
>>>>>> backgroud process as you pointed out.
>>>>>
>>>>> My opinion was already expressed after I had finished the tests from
>>>>> my side: the boost can be achieved in specific conditions, so whether
>>>>> it's worth including into Harmony really depends on how much mess the
>>>>> patch would introduce besides the "performance boost". From what I
>>>>> see, the patch obliges the maintainer to maintain the correct mapping
>>>>> between jars and Java packages. This new feature is also spread
>>>>> between Classlib and VM, but it seems like DRLVM specific. In this
>>>>> case I would rather stay without the patch.
>>>>>
>>>>> Personally (if I'll be committer) I would accept the patch with two
>>>>> serious modifications:
>>>>>  1. Stay within DRLVM, do not introduce this feature into Classlib,
>>>>> get the thing tested and evolved on DRLVM side. Otherwise it might
>>>>> break the compatibility with other VMs.
>>>>>  2. Make the mapping generated automatically (during build process?)
>>>>> to free the burden for maintainers.
>>>>>
>>>>> Thanks,
>>>>> Aleksey.
>>>>>
>>>>
>>>
>>
>