From: Laurence H. <L.H...@ke...> - 2010-01-24 09:29:29
|
On 24 Jan 2010, at 02:03, Colin(Du Li) wrote: > > Hi, guys, > > In the Magic class, there are two methods like this: > getWordAtOffset(Object object, Offset offset) > getWordAtOffset(Object object, Offset offset, int locationMetadata) > > I don't what's the difference between the two methods. What is the > "locationMetadata"? Is there any place inside jikes rvm(including mmtk) need > the "locationMetadata"? Does opt compiler need it ? why? Hi, The location metadata encodes the FieldReference instance that represents the field being read or written (see org.jikesrvm.classloader.FieldReference for details, and look at how primitiveObjectFieldStoreHelper is called within org.jikesrvm.compilers.opt.hir2lir.ExpandRuntimeServices for an example of getting and passing the FieldReference to a MMTk barrier. The Opt compiler uses the FieldReference information (when known) to detect aliased reads and writes and ensure suitable dependancies are maintained whilst generating optimised code. The base compiler does no code reordering so silently ignores the FieldReference information. MMTk doesn't need to care about the location metadata - it is JikesRVM specific meta-data whilst MMTk is VM neutral. The FieldReference metadata is passed into MMTk in an opaque way as a Word (metaDataB) and MMTk merely passes this information back to the compilers when making the magic call that actually does the read / write. When implementing primitive write barriers I added lots of Magic.setXAtOffset methods to increase type safety. I also added versions of these Magic calls that took location metadata and actually made sure the opt compiler used the information. I'm not sure that I add all the corresponding getXAtOffset methods and appropriate compiler modifications so their might be some more work to do there. Hopefully the above helps Kind regards Laurence Laurence Hellyer Research Student School of Computing University of Kent More info: http://www.cs.kent.ac.uk/people/rpg/lh243/ |