RFR(S) 8169938: [AOT] SIGSEGV at ~BufferBlob::vtable chunks

[dean.long at oracle.com]

Thanks Tom.

dl


On 12/20/16 8:30 PM, Tom Rodriguez wrote:
>
>> On Dec 20, 2016, at 7:01 PM, dean.long at oracle.com 
>> <mailto:dean.long at oracle.com> wrote:
>>
>> 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 <mailto: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?
>
> From the perspective of code generation the allocation paths do this. 
>  But to answer my own question, I think c2 may be setting it to true 
> under conditions where it will never be consulted.  Any VM entry point 
> that actually returns an oop uses a stub to handle it and passes the 
> value through vm_result so it’s handled across the safe point.  You 
> can't actually stop at the call site pc when you deoptimize.  I think 
> a correct value is only required for real Java invoke sites.
>
>>
>>> 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”);
>
> The code is using isa_ptr() so any pointer return value will set it to 
> true which is clearly wrong.  I suspect any path which might set this 
> incorrectly simply will never consult the value.
>
> So I think your fix for JVMCI looks right.  And the existing C2 code 
> is benignly wrong.
>
> tom
>
>>
>> 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 
>>>>> <mailto: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
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20161220/95c576a2/attachment.html>