Aleksey Shipilev wrote: > On Nov 21, 2007 9:21 PM, Tim Ellison <[EMAIL PROTECTED]> wrote: >> I see, that makes sense. So perhaps we should not bother with the >> current basing option in makefiles, and just leave it all to the >> deployment stage? > We might just leave them alone and rebase again on the deployment stage. > That's the minumim change which allows to use large heaps.
I'm more interested in doing the 'right thing' rather than the 'minimum change', but I won't argue strongly for it. >> Looking at the doc for editbin, I agree that /largeaddressaware looks >> like a good option too. How about /bind ? Given we just rebased the >> DLLs it may help with start-up times? > That makes sense for the sake of modularity, sure, but that's not the > post-build action since we don't know what libraries will be used > exactly. So we need to prepare for the worst case and relocate most of > them. Are we talking about the same thing. If I read /bind properly it preloads the addresses of entry points assuming that the DLLs do not conflict -- which we hope will be true after rebasing. >> I may tweak that patch a bit so it doesn't try to rebase the DLLs in the >> bin/default directory if the VM isn't DRLVM. Not sure what the effect >> would be on the IBM VME (at least, some of those files don't appear in >> the IBM/BEA VM). > Uhm... I thought my patch only touches DRLVM-specific build code. Are > the same scripts used for Harmony/J9 building? If yes, sure, we can > ensure compatibility with other VMs as well. Yes, I saw the patch's "Index: build/make/build.xml" and jumped to the wrong conclusion. You are right that it should only affect the DRLVM build this way. Regards, Tim
