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. >>>>> >>>> >>> >> >
