CompilerDirectives unsafeGet/Put and location identity

[John Rose]

On Apr 25, 2014, at 9:16 AM, Stefan Marr <java at stefan-marr.de> wrote:

> How is the location identity supposed to be used for unsafe access operations in the CompilerDirectives?

You can check the code in HotSpot's library_call.cpp for inline_unsafe_access, which deals with the same problems.

Short answer:  Given unknown inputs, an unsafe access can touch (in principle) any alias category.  That requires a couple of fences of type "CPU order" to block motion of all other accesses.  (I hear the C++ "monotonic access" concept is similar to CPU order.)

But, an unsafe access can be improved to touch only one alias category, if the inputs are sharp enough.  In particular, if the base address is to a class (or other layout, maybe a python layout) and the offset is a constant falling within that class's layout, then the access is equivalent to a regular field access, and can be de-aliased from all other accesses.  With such nodes there is no need for the CPU order fences.

Can this happen?  Yes, I think it can, when generic code operates on a field-descriptor metadatum of some sort, that becomes constant enough.  Method handles (Lookup.findSetter, etc.) can do this; if the MH becomes a compile-time constant, then its fields can be made constants, and they in turn force the inputs to the unsafe accesses to get sharp.

HTH
— John