Unsafe access and aot-image building

[Christian Wimmer]

Stefan,

You might not have all necessary substitutions in place yet.

If the ObjectDirectStorageLocation instance is created during native 
image generation, then it still has the wrong field offset in place. In 
that case, you need a separate substitution also for 
ObjectDirectStorageLocation.fieldOffset

Even if you don't have such instances in the image (yet), you can add 
the substitution, it doesn't hurt. And then the verification will pass too.

If you access a field directly via its offset, you have to register that 
field in a Feature.beforeAnalysis method with registerAsUnsafeWritten()

In general, you have to be very careful when accessing fields with 
unsafe and when handling raw field offsets. For example, field order is 
different between HotSpot and Substrate VM. So what you think is the 
"first field" might no longer be the first field in the image. And 
finding all places where a field offset might leak to is non trivial.

-Christian




On 06/15/2017 04:03 PM, Vojin Jovanovic wrote:
> Hi Stefan,
> 
> What fails is the verification that use to avoid accidental SEGFAULTS 
> that requires the `fieldOffset` to be recomputed which is not the case 
> here. What you did is correct, but our verification is too narrow to 
> figure that out. We will find a way to loosen this verification step for 
> the future.
> 
> For now, you can disable offset verification by adding
> 
>    -H:-ThrowUnsafeOffsetErrors
> 
> to your image build command.
> 
> Hope this helps.
> 
> Cheers,
> 
>   -- Vojin
> 
> On 6/15/17 10:52 AM, Stefan Marr wrote:
>> Hi:
>>
>> I am experimenting with using SVM/the AOT image building from GraalVM 
>> 0.24 for SOMns.
>>
>> One difficulty is that I am not aware of much publicly available 
>> information.
>> So, I am kind of flying blind here.
>>
>> The next challenge is that SOMns still uses my own object model, which 
>> is implemented with unsafe operations. And, I’d really like to keep 
>> it, if at all possible.
>>
>> With a bit of guidance, I got so far that I get the following error:
>>
>> error: Field 
>> AnalysisField<StorageLocation$ObjectDirectStorageLocation.fieldOffset 
>> accessed: false reads: true written: true> is used as an offset in an 
>> unsafe operation, but no value recomputation found.
>>
>> And the `fieldOffset` is the offset used by the unsafe access.
>>
>> In code [1] this looks like this:
>>
>> public static final class ObjectDirectStorageLocation {
>>
>>      private final long fieldOffset;
>>
>>      public ObjectDirectStorageLocation(final ObjectLayout layout, 
>> final SlotDefinition slot,
>>          final int objFieldIdx) {
>>        super(layout, slot);
>>        fieldOffset = SObject.getObjectFieldOffset(objFieldIdx);
>>      }
>>
>>
>>
>> The underlying problem is that this of course depends on functionality 
>> to determine the object offset, roughly something like this:
>>
>>    private static long FIRST_OBJECT_FIELD_OFFSET = 
>> getFirstObjectFieldOffset();
>>    private static final long OBJECT_FIELD_LENGTH = 
>> getObjectFieldLength();
>>    public static final int NUM_OBJECT_FIELDS    = 5;
>>
>>    public static long getObjectFieldOffset(final int fieldIndex) {
>>      assert 0 <= fieldIndex && fieldIndex < NUM_OBJECT_FIELDS;
>>      return FIRST_OBJECT_FIELD_OFFSET + fieldIndex * 8 /* 
>> OBJECT_FIELD_LENGTH */;
>>    }
>>
>> `getFirstObjectFieldOffset()` is normally using reflection, but 
>> Peter’s help, I used the svm.jar to build a replacement class, which 
>> is supposed to make sure that the image will use the correct offset 
>> for the object access at run time:
>>
>> @TargetClass(SObject.class)
>> public final class SObjectReplacement {
>>    @RecomputeFieldValue(kind = Kind.FieldOffset, declClass = 
>> SMutableObject.class, name = "field1")
>>    @Alias
>>    private static long FIRST_OBJECT_FIELD_OFFSET;
>> }
>>
>> However, when I do this, it still has cause the very same error.
>> I am sure that SVM picks up the SObjectReplacement class, because it 
>> throws an error if the class is not marked final.
>>
>> Any help, pointers, and suggestions would be very welcome.
>> I suppose I am missing something to make the analysis happy with the 
>> replacement. But I have no clue what that might be.
>> Do I need to do something with the `fieldOffset` field itself, instead 
>> of the fields it relies indirectly on?
>>
>> Thanks
>> Stefan
>>
>>
>>
>> [1] 
>> https://github.com/smarr/SOMns/blob/master/src/som/interpreter/objectstorage/StorageLocation.java#L152 
>>
>>
>