[jmm-dev] bitwise RMW operators, specifically testAndSetBit/BTS

John Rose john.r.rose at oracle.com
Wed Jul 20 00:44:33 UTC 2016


On Jul 19, 2016, at 5:31 PM, John Rose <john.r.rose at oracle.com> wrote:
> 
> What I mean by "loosen its grip" is share enough layout information about pointers that Java code can find and use a slack bit in the pointer format.  (And if there isn't such a bit, then Java code would have to go away and do something else.)  Also, for pointers which are treated this way, the GC would have to mask off the shared bits.

P.S.  One more thought on this:  We probably need a special marking for
pointer variables which have this funny property.  The JVM can lay them
out with 64 bits even when they are compressed, and then inform Java
code how many slack bits are available.  Some days 32 (compressed
oops), some days 3 (all 61 high bits are significant) and some days 8/16/24.
In the non-compressed case, the GC will have to mask off the bits which
the JVM shares with the Java code.

This is related to some work Rickard Backman did in 2012, where a 64-bit
pointer variable could also contain non-pointer bits usable for any purpose.
In that case, the bits were mutually exclusive with the pointer, and a tag
scheme would tell the GC and everybody else what was in the variable.
This is a different semantics from "stolen" color bits or flag bits, but has
many of the same implementation moves.

http://cr.openjdk.java.net/~rbackman/tagged.patch/mlvm.hs.patch

In the future, we can probably use value types as a principled way
to mark such special variables for special processing by the JVM.
(I'm thinking TaggedReference<T>, Contended<T>, WeakReference<T>,
etc.  Details to be worked out later…)



More information about the jmm-dev mailing list