harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aleksey Shipilev" <aleksey.shipi...@gmail.com>
Subject Re: [VM] On-demand class library parsing is ready to commit
Date Thu, 25 Dec 2008 16:29:15 GMT
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.


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> 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>
>>>>>> 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>
>>>>>>> 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>
>>>>>>>>> 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
>>>>>>>> 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
>>>>>>>> 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
>>>>>>>> to free the burden for maintainers.
>>>>>>>> Thanks,
>>>>>>>> Aleksey.

View raw message