harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexei Fedotov" <alexei.fedo...@gmail.com>
Subject Re: [VM] On-demand class library parsing is ready to commit
Date Thu, 25 Dec 2008 16:49:06 GMT
I like your conclusion.

I'm trying to understand the real life value of the "abstract" startup
time metric you've suggested. Does Harmony with your patch load
swing.jar for a server application? Do I understand that loading
happens, though it happens later compared to VM without your patch? I
believe that the proper design of delayed loading should answer "no"
to this question.

In other words, I appreciate if you describe which real use cases are
improved by this patch.

On Thu, Dec 25, 2008 at 7:29 PM, Aleksey Shipilev
<aleksey.shipilev@gmail.com> wrote:
> Ok, here's the catch.
> bootclasspath.properties is the SortedSet<JARfile>, which enumerates
> the JARs available for bootclassloader. The set of such the JARs is
> really stable because modular decomposition of classlib is stable.
> That's why nobody bothers with automatic generation of it: it only
> should be updated when new JAR file arrives.
> Modulelibrarymapping.properties is different on this point, it's the
> Map<PackageName,JARfile>, which should be updated each time the new
> *package* is introduced. I'm not talking about java.* packages
> (they're standardized), rather about org.apache.harmony.*.
> Automatic generation of this property file gives two advantages:
>  1. Error-prone. Prevent yourself from hand-messing with mapping and
> getting spurious ClassNotFoundException. BTW, what's the behaviour in
> case the mapping is wrong?
>  2. "Researchful". There're lot of guys around who enjoys the
> modularity of Harmony classlib and eventually they might want to split
> the packages even deeper, into smaller pieces. Then automatic
> generation would enable them to quickly roll-in and experiment with
> different package layouts and their impact on performance. They could
> use ordinary bootclasspath.properties, but your feature wouldn't be
> used by them then ;)
> That's merely a housekeeping procedure. I believe that anything which
> could be done more than once, eventually would be done more than once.
> Hence it should be automated. You say that the file was generated from
> manifests of JARs, so is it hard to just tie the same tool into DRLVM
> build process?
> As for DRLVM-specific, my opinion that this is because the patch:
>  a. breaks the compatibility of classlib (you change
> bootclasspath.properties, right?) with other VMs.
>  b. treated in DRLVM classloader only.
> Of course eventually this feature might be used by others, but IMO we
> should be careful about other guys who use the same classlib. I'd
> rather wait for some incubation on DRLVM side first.
> Thanks,
> Aleksey.
> On Thu, Dec 25, 2008 at 6:18 PM, Wenlong Li <wenlong@gmail.com> wrote:
>> I see. In fact, my file doesn't need track change at the class
>> granularity. Instead, it only needs know package info provided in the
>> manifest file.  When class is added to a library, do we need change
>> the manifest as well?
>> btw, I guess there is a mis-understanding: my modulelibrarymapping
>> file only records package info provided by manfiest in each module. It
>> doesn't relate to each class.
>> thx,
>> Wenlong
>> On Thu, Dec 25, 2008 at 10:55 PM, Pavel Pervov <pmcfirst@gmail.com> wrote:
>>> Classes are added to class library from time to time. I'm not sure how
>>> it can be possible to track these changes manually.
>>> WBR,
>>>    Pavel.
>>> On Thu, Dec 25, 2008 at 5:09 PM, Wenlong Li <wenlong@gmail.com> wrote:
>>>> 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>
>>>>> 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>
>>>>>> 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>
>>>>>>> Wenlong,
>>>>>>> Note, that bootclasspath.properties is only changed on adding
>>>>>>> module. This is pretty rare occasion, I believe.
>>>>>>> WBR,
>>>>>>>    Pavel.
>>>>>>> On Thu, Dec 25, 2008 at 3:48 PM, Wenlong Li <wenlong@gmail.com>
>>>>>>>> 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
>>>>>>>> optimization, e.g., it targets for improving VM creation
time. So that
>>>>>>>> is possible to move all updates to DRLVM part to eliminate
>>>>>>>> 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>
>>>>>>>>>> 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
>>>>>>>>> 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.

С уважением,
Алексей Федотов,
ЗАО «Телеком Экспресс»
View raw message