From: David P G. <gr...@us...> - 2006-01-27 22:29:02
|
I've just checked in a fairly hefty rewrite of the bootimage writer that has the effect of splitting the RVM bootimage into 2 files. One file (RVM.code.image) contains all of the executable code in the bootimage, the other (RVM.data.image) contains all of the data. The files are mapped to separate address ranges. As far as the bootimage writer is concerned, the address ranges are completely arbitrary (but must not overlap). Currently the VM/MMTk constrain things such that the bootimage data must be the lowest region of mapped memory, followed by the bootimage code, followed by the rest of the heap spaces. It might be nice to generalize this to eliminate these constraints, but I think that's mainly a matter for MMTk, so I'll leave it to those who know it better than I. When you update from this change, if you maintain any local configuration files, instead of defining BOOTIMAGE_LOAD_ADDRESS, you must define both BOOTIMAGE_DATA_ADDRESS and BOOTIMAGE_CODE_ADDRESS. I've updated all the config files in cvs (see rvm/config/* for examples if necessary) and on the nightly regression machines. I tested the changes on Linux/IA32, PowerPC/AIX/32 and PowerPC/AIX64. The nightly tests should pick up most of the other platforms, but if you see something broken let me know. --dave |
From: Steve B. <Ste...@an...> - 2006-01-27 22:49:05
|
Great work Dave!!! I think the only real MMTk contraint is that for performance reasons, it is best if immortal spaces are all at one end of memory (the opposite end to the nursery). The bootimage data is one of the immortal spaces. For most collectors the constraint is even weaker than this, but there are some where the address space must have at least three well ordered parts: immortal, mature & nursery. Robin, Daniel and I can take a look at this (though we are all going to be out of town for most of next week). Cheers, --Steve David P Grove wrote: >I've just checked in a fairly hefty rewrite of the bootimage writer that >has the effect of splitting the RVM bootimage into 2 files. One file >(RVM.code.image) contains all of the executable code in the bootimage, the >other (RVM.data.image) contains all of the data. The files are mapped to >separate address ranges. As far as the bootimage writer is concerned, the >address ranges are completely arbitrary (but must not overlap). Currently >the VM/MMTk constrain things such that the bootimage data must be the >lowest region of mapped memory, followed by the bootimage code, followed >by the rest of the heap spaces. It might be nice to generalize this to >eliminate these constraints, but I think that's mainly a matter for MMTk, >so I'll leave it to those who know it better than I. > >When you update from this change, if you maintain any local configuration >files, instead of defining BOOTIMAGE_LOAD_ADDRESS, you must define both >BOOTIMAGE_DATA_ADDRESS and BOOTIMAGE_CODE_ADDRESS. I've updated all the >config files in cvs (see rvm/config/* for examples if necessary) and on >the nightly regression machines. > >I tested the changes on Linux/IA32, PowerPC/AIX/32 and PowerPC/AIX64. The >nightly tests should pick up most of the other platforms, but if you see >something broken let me know. > >--dave > > >------------------------------------------------------- >This SF.net email is sponsored by: Splunk Inc. Do you grep through log files >for problems? Stop! Download the new AJAX search engine that makes >searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! >http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 >_______________________________________________ >Jikesrvm-core mailing list >Jik...@li... >https://lists.sourceforge.net/lists/listinfo/jikesrvm-core > > |