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

[Tom Rodriguez]

> On Dec 20, 2016, at 7:01 PM, 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> 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 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