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 <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote: >>> If this would be VM-side automatically produced configuration file... >>> >>> WBR, >>> Pavel. >>> >>> On Thu, Dec 25, 2008 at 4:58 PM, Wenlong Li <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 >>>>>> <[email protected]> wrote: >>>>>>> Hi, Wenlong. >>>>>>> >>>>>>> On Thu, Dec 25, 2008 at 11:49 AM, Wenlong Li <[email protected]> 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. >>>>>>> >>>>>> >>>>> >>>> >>> >> >
