RVM

I have been working on a patch to refactor the object model. As part of this the locking code was refactored. The basic structure is:

org.jikesrvm.objectmodel

general purpose access

org.jikesrvm.objectmodel.locking

abstractions of locking models

org.jikesrvm.objectmodel.hashing

abstractions of hashing models

With this approach you can currently build with fat locks, thin locks and any combination of hashing model. The code is written in such a way that redundant status word bits will be used depending on how the object model instance is created.

More specifically:

rvm/src/org/jikesrvm/objectmodel/
rvm/src/org/jikesrvm/objectmodel/JavaHeaderConstants.java
rvm/src/org/jikesrvm/objectmodel/FieldLayoutUnpacked.java
rvm/src/org/jikesrvm/objectmodel/InsufficientBitsError.java
rvm/src/org/jikesrvm/objectmodel/header/
rvm/src/org/jikesrvm/objectmodel/header/Header.java
rvm/src/org/jikesrvm/objectmodel/header/locking/
rvm/src/org/jikesrvm/objectmodel/header/locking/ThinLockStatus.java
rvm/src/org/jikesrvm/objectmodel/header/locking/LockStatus.java
rvm/src/org/jikesrvm/objectmodel/header/hashing/
rvm/src/org/jikesrvm/objectmodel/header/hashing/CounterBasedHashStatus.java
rvm/src/org/jikesrvm/objectmodel/header/hashing/HashStatus.java
rvm/src/org/jikesrvm/objectmodel/header/hashing/AddressBasedHashStatus.java
rvm/src/org/jikesrvm/objectmodel/header/DefaultHeader.java
rvm/src/org/jikesrvm/objectmodel/OldJavaHeader.java
rvm/src/org/jikesrvm/objectmodel/RelativeToObjectReference.java
rvm/src/org/jikesrvm/objectmodel/tables/
rvm/src/org/jikesrvm/objectmodel/tables/ITableArray.java
rvm/src/org/jikesrvm/objectmodel/tables/RuntimeTable.java
rvm/src/org/jikesrvm/objectmodel/tables/ITable.java
rvm/src/org/jikesrvm/objectmodel/tables/TIB.java
rvm/src/org/jikesrvm/objectmodel/tables/IMT.java
rvm/src/org/jikesrvm/objectmodel/tables/TIBLayoutConstants.java
rvm/src/org/jikesrvm/objectmodel/MiscHeader.java
rvm/src/org/jikesrvm/objectmodel/NewObjectModel.java
rvm/src/org/jikesrvm/objectmodel/FieldLayoutContext.java
rvm/src/org/jikesrvm/objectmodel/ObjectModel.java
rvm/src/org/jikesrvm/objectmodel/FieldLayout.java
rvm/src/org/jikesrvm/objectmodel/BootImageInterface.java
rvm/src/org/jikesrvm/objectmodel/FieldLayoutPacked.java
rvm/src/org/jikesrvm/objectmodel/MiscHeaderConstants.java
rvm/src/org/jikesrvm/objectmodel/RelativeToStartOfObject.java

some of what there is cruft that I'm in the process of moving to the new model. The basic idea is that you can bolt together a header, the default header replicating the current header. The other part of this is to make the approach also agnostic to object layout. In particular bidirectional object layout and the use of handles into an object table rather than direct access to objects.

WIP new object model code.

This looks cool! I think it is orthogonal to my code - what I'm doing is looking at different ways of doing locking under the assumption that you have a ~20 bit (or whatever the object model gives me) "lock word", which I can then interpret as being a thin lock word, a biased lock word, or whatever. I'll proceed undaunted for now, but at some point we may end up merging.

My thinking is you'd want one package to deal with the implementation of locking (what I'm doing), and another to deal with the representation of the lock word in the object model. These can be orthogonal, and their interaction can be limited. Agreed?

I agree the changes are largely orthogonal. There are possible interactions:

1) we tend to define constants (which to me look like C style .h file - yuck) and then these permeate the code base, the new model requires the implementation to call back into the object model so that the layout of objects is abstracted

2) the compilers currently have explicit information about how to optimize for thin locks (ie inline particular methods). We need to abstract this in much the same way as MMTk has abstracted barriers.

My plan had been that whenever the compiler needed to interact with an object it did this via the object model. For monitors there was a runtime entrypoint that bounced into the object model which via its header would then interact with the scheduler.

The attached code is a WIP and I would be happy for it to get merged with this work and forward progress made. I'm currently trying to fix Harmony (with a large rewrite of most of the syscalls).

The work needed on this code is:
1) bring it up-to-date with trunk
2) remove all uses of the old object model to move it to the new object model
3) test the abstraction out - hopefully with a bidirectional model, but there are also issues with squeezing the header size on 64bit platforms
4) handle the misc header in some kind of clean and elegant way (it's a frequent issue for users)

I also think that the object model should probably be abstracting static field accesses. This could allow us to have multiple static field implementations, such as the JTOC vs. hanging statics off of RVMClass vs. hanging statics of CodeArray.

There's lots of work to do, I just really wanted you to have a heads up on what my thinking is. I've tried to capture this in the past through JIRA entries.

I had also been talking to Athul at Purdue about merging his biasing code. I've not heard from him recently though. I think biasing needs to be approached with caution. There are HotSpot applications that report a 30% slow down with its use as in the current HotSpot (and they have a lot more developer effort to try to get it right).

Done with merge in of biased locking code?

Biased locking has been merged. The system is still not as modular as I'd like it to be for further research, so I may revisit it. But for now I consider the issue closed.