RFR(S) 8169938: [AOT] SIGSEGV at ~BufferBlob::vtable chunks
tom.rodriguez at oracle.com
Tue Dec 20 21:44:07 UTC 2016
> 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?
> 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.
More information about the hotspot-compiler-dev