CompilerDirectives unsafeGet/Put and location identity

[Tom Rodriguez]

The location identity is the alias class of a memory operation.  Loads and stores involving different alias classes are considered totally independent so you must be careful to specify a stable entity for the location identity object.  Passing null for the location identity turns it into ANY_LOCATION which aliases with everything.  So switching to null probably means that the location identity is incorrectly specified, though it could end up hiding the real problem.  Ideally it should be a singleton object used by all loads and stores to a particular piece of memory.  In your code, "this" is a Node instance which is new for every operation, so you’re creating a new alias class each time.  That’s definitely going to do bad things.

If you have a piece of metadata that represents a logical field in a type that can be used for the identity.  That’s what’s done for Java.  A ResolvedJavaField represents a field declared by a particular class and that object serves as it’s identity.  Arrays are handled specially.  A very quick hack could use a Map keyed by fieldOffset to return a shared object.  You’d get aliasing between types at the same offset but it’s better than ANY_LOCATION.

I don’t know how broadly unsafe is used by Truffle clients but a more formal API for those location objects would make this a lot clearer.

tom

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

> Hi:
> 
> How is the location identity supposed to be used for unsafe access operations in the CompilerDirectives?
> 
> I saw that Wei changed ZipPy’s use of these methods from passing the node identity to passing null [1].
> The commit messages mentions a ‘compiler error’. 
> 
> For TruffleSOM, this introduced a correctness issue earlier this month (see the mail here [2]).
> 
> Passing null indeed also solvers my correctness issues, but I still would like to understand whether that’s a compiler bug that is going to be fixed, or whether I used [3] the location hint in a way that it wasn’t supposed to be used.
> 
> Thanks
> Stefan
> 
> [1] https://bitbucket.org/ssllab/zippy/commits/446cf4cff0b80e8fb893d6f75861839f7cca4b4d
> [2] http://markmail.org/message/iulklm27azer3joi
> [3] https://github.com/SOM-st/TruffleSOM/commit/28e0af52687618c987541b1c32f2a8335a43fc5e
> 
> -- 
> Stefan Marr
> INRIA Lille - Nord Europe
> http://stefan-marr.de/research/
> 
> 
>