RFR(S) 8169938: [AOT] SIGSEGV at ~BufferBlob::vtable chunks
dean.long at oracle.com
dean.long at oracle.com
Wed Dec 21 03:01:52 UTC 2016
On 12/20/16 3:34 PM, Vladimir Kozlov wrote:
> On 12/20/16 1:44 PM, Tom Rodriguez wrote:
>>
>>> On Dec 19, 2016, at 1:50 PM, Vladimir Kozlov
>>> <vladimir.kozlov at oracle.com> wrote:
>>>
>>> Thank you, Dean, for finding the cause.
>>>
>>> Looks good to me.
>>>
>>> CCing to Graal since it affects it. I am curious why Labs did not
>>> hit it before.
>>
>> Not sure either, though AOT’s been running for a while without seeing
>> it either.
>>
>> I’m a unsure that this is the right logic though. If you look at how
>> C2 is setting this flag it’s driven by lower level code generation
>> details. Basically it’s looking at the underlying call object at the
>> debug info site to determine if that call is returning an oop. Will
>> that produce the same answer as checking the return type of the
>> call? For any site which is a normal method invoke I think it will
>> but what about other calls like a vm entry point?
>
Is there a VM entry point that returns an oop in a register?
> I agree, C2 is checking is_ptr() which include metadata pointers.
>
It must be an oop, not metadata:
oop result = deoptee.saved_oop_result(&map);
assert(result == NULL || result->is_oop(), "must be oop");
dl
> In such case we need help from you. I think pointer return information
> can be recorded in DebugInfo or Call class.
>
> Thanks,
> Vladimir
>
>>
>> tom
>>
>>>
>>> Thanks,
>>> Vladimir
>>>
>>> On 12/19/16 1:22 PM, dean.long at oracle.com wrote:
>>>> AOT code, like C2 code, can reallocate objects during deoptimization,
>>>> because of escape analysis. To support this, we need to set the
>>>> "return_oop" flag on the scope correctly.
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8169938
>>>> http://cr.openjdk.java.net/~dlong/8169938/webrev/
>>>>
>>>> dl
>>>>
>>
More information about the graal-dev
mailing list