Request for Review(S): JVM crashes when throwing StackOverflow exception from interpreter

[Bertrand Delsart]

Sorry,

I was notified of the CR and got involved in the bug because we were 
wondering whether the bug was impacting our embedded ports. I sent my 
own review in an internal alias but should have let you know. FYI, we 
were still discussing it because I raised some issues about the proposed 
fix.

First, thanks for spotting the bug! We do agree with the first problem. 
We should indeed ensure that SP is correct.

My concerns were about the second part.

First, the change is doing more that just going through the stub. It 
seems that your are trying to solve a third problem. x86 was already 
using the throw_StackOverflowError_entry stub. What your proposed change 
seems to imply is that you encountered a case where the stub had not yet 
been generated and hence you had to delay the loading of its address. Is 
that correct ?

In addition, the explanations about why we have to go through that stub 
did not fit my knowledge of HotSpot and I was trying to clarify that 
internally (thanks Tom for your confirmations).

With our Java ABI, none of the registers allocated by the compiler are 
callee-saved. Hence, at call sites, the GC should not have to update any 
  OOP in callee-saved registers (but might have to update arguments). If 
fixing SP is not sufficient to solve your test case on SPARC then the 
problem is not exactly what you describe.

Now, that does not mean the fix would not be correct :-) Going through 
that stub might be safer anyway, particularly since we are doing it on 
x86. My issues are about the comments themselves (and the third problem 
mentioned above).

Thanks,

Bertrand.

On 12/13/11 09:19 PM, Christian Thalinger wrote:
>
> On Dec 7, 2011, at 10:45 AM, Volker Simonis wrote:
>
>> There's now a bug report for this issue:
>>
>> 7116216: StackOverflow GC crash
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7116216
>>
>> so could somebody please have a look at the fix proposed by Yang?
>
> Sorry, I will have a look tomorrow.
>
> -- Chris
>
>>
>> Regards,
>> Volker
>>
>> On Wed, Nov 16, 2011 at 6:04 PM, Wang, Yang<yang02.wang at sap.com>  wrote:
>>> Hi folks,
>>>
>>>     We found two problems during throwing an StackOverflow exception from
>>> interpreter.
>>>
>>> 1.       Before preparing to throw a StackOverflow exception, the last Java
>>> frame is set to the current sp. This is problematic when the StackOverflow
>>> is thrown on top of c2i adapter. Solution : the real caller frame(unextended
>>> sp) should be set as last Java frame.
>>>
>>> 2.       When Garbage collection happens during throwing StackOverflow
>>> exception, and callee-saved register(or "never-saved" register which behaves
>>> alike) happens to be an OOP, GC is unable to locate the OOP in C
>>> frame(generated by VM calls), and hence fails to process the OOP. Solution :
>>> We build a runtime stub frame before doing a VM call, which guarantees the
>>> location of Callee-saved registers are always recognizable by GC.
>>>
>>>     Detailed descriptions and tests could be found in webrev
>>>   http://www.sapjvm.com/yw/webrevs/StackOverflow_GC_Crash/
>>>
>>>     I don’t have a bugID yet. Please kindly open one bug for this issue.
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Yang
>>>
>>>
>>>
>>>
>>>
>>> Yang Wang
>>> Software Engineer
>>>
>>> TIP Core AS&VM Technology (AG)
>>> SAP JVM JIT Compiler
>>>
>>> SAP AG
>>> Dietmar-Hopp-Allee 16
>>> 69190 Walldorf, Germany
>>>
>>> T +49 6227 7-50320
>>> F +49 6227 78-48541
>>> Email : yang02.wang at sap.com
>>> www.sap.com
>>>
>>>
>>> Pflichtangaben/Mandatory Disclosure Statements:
>>> http://www.sap.com/company/legal/impressum.epx
>>>
>>> Diese E-Mail kann Betriebs- oder Geschäftsgeheimnisse oder sonstige
>>> vertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrtümlich
>>> erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine
>>> Vervielfältigung oder Weitergabe der E-Mail ausdrücklich untersagt. Bitte
>>> benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail. Vielen
>>> Dank.
>>>
>>> This e-mail may contain trade secrets or privileged, undisclosed, or
>>> otherwise confidential information. If you have received this e-mail in
>>> error, you are hereby notified that any review, copying, or distribution of
>>> it is strictly prohibited. Please inform us immediately and destroy the
>>> original transmittal. Thank you for your cooperation.
>>>
>>>
>


-- 
Bertrand Delsart,               bertrand.delsart at oracle.com,
Sun-Oracle France, 180 av. de l'Europe, ZIRST de Montbonnot,
38334 Saint Ismier,                                  FRANCE