[jira] Commented: (RVM-819) RefCount broken

    [ http://jira.codehaus.org/browse/RVM-819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=175618#action_175618 ]

Filip Pizlo commented on RVM-819:
---------------------------------

The problem is that biased locking does not allow mutators to CAS on the status word except when the world is stopped.  This is because the biased locking wants to be able to inc/dec the lock recursion count without atomic intructions; this is essential for the performance win.  The deeper reason is that our status word is organized into bits rather than bytes.  In particular, we assign some number of bits for the GC, and then some number of bits for the hash, and some number of bits for the lock.  Hence, for these operations to be able to cooperate, they either need to:

1) Use CAS, which is bad for biased locking, or

2) Have some other sync mechanism - which is what biased locking does in non-RC configurations.  If the GC doesn't want to CAS the status word outside of STW GC, then the only thing that remains is the hash code logic.  The hash code logic under biased locking uses ThinLock.lockHeader to get a "lock" on the status word (this is not the same as locking the object - its semantics are more subtle than that to prevent livelocks), and then after acquiring this lock, it accesses the status word without using CAS because it has exclusive access.  But, this breaks under RC because the GC wants to CAS the status word, which trips an assertion in the object model that says that this is not allowed because the biased locking code has exclusive access to that word unless ThinLock.lockHeader is called.

There are three potential solutions:

A) Have RC call ThinLock.lockHeader.  This is obviously bad as it would incur a huge performance penalty.

B) Disable biased locking under RC.

C) The best solution: segregate the status word into bytes.  The GC gets its own byte.  The biased locking code could then devote a 16-bit word to the recursion count plus some other bits, and use part of the fourth byte for some of its other bits, giving the rest of that fourth byte to the hash code.  This would allow biased locking to perform inc/dec on the recursion count without using atomic instructions and without disturbing the RC code.  The RC code could then use CAS on either the whole status word (such a CAS would fail spuriously under concurrent modifications to other parts of the status word, but that would be rare) or else use a CAS on the GC byte of the status word, if byte CAS is possible on the given architecture (I cannot remember if Intel has a byte CAS; I think it does).

For now, I've implemented option (B), which seems to work.  I'm doing pre-commit tests right now and will commit shortly.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
Jikesrvm-issues mailing list
Jikesrvm-issues@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-issues