CompilerDirectives unsafeGet/Put and location identity

Wei Zhang ndrzmansn at gmail.com
Fri Apr 25 20:52:07 UTC 2014


Hi Stefan,

In TruffleSOM's FieldAccessor node, you could pass an object that abstracts
the field offset to the unsafeGet/Put as the location identity.
ZipPy uses a Location object to abstract the physical offset of an
attribute in a PythonObject (not my original idea).

https://bitbucket.org/ssllab/zippy/src/7ecc49428b526999f3f18bd9cf1b052afbac2791/graal/edu.uci.python.runtime/src/edu/uci/python/runtime/object/IntStorageLocation.java?at=default

This location object is close to the field metadata that Tom explained.


Hi Andreas,

What would be the use case of CompilerDirectives.unsafeGetFinal* methods?

Thanks,

/Wei


On Fri, Apr 25, 2014 at 11:24 AM, Andreas Woess <andreas.woess at jku.at>wrote:

> Hi Stefan,
>
> Short answer: we indeed have a compiler problem with Truffle's unsafeGet*
> methods in combination with a few optimizations at the moment. It's better
> to always pass false as the condition parameter for now (the condition
> shouldn't be true here anyway). If that does not solve the problem, it's
> likely an issue of location identity used incorrectly (see Tom's reply) --
> location identity null is on the safe side.
>
> - andreas
>
>
> On 25/04/14 18:16, Stefan Marr 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
>>
>>
>


More information about the graal-dev mailing list