RFR(S): 8216376: [PPC64] Possibly unreliable stack frame resizing in template interpreter

[Doerr, Martin]

Hi Götz,

I don't think it has a measurable impact on interpreter performance. Especially not for out-of-order CPUs. The additional ld/st is only used once for each special interpreter entry.

The PPC64 ABI only specifies that 288 bytes below SP are preserved (e.g. by interrupt handler). How else should we ensure that the backlink is not overwritten?
I think an assertion is not appropriate. We should better comply with the ABI.

Best regards,
Martin


-----Original Message-----
From: Lindenmaier, Goetz 
Sent: Mittwoch, 9. Januar 2019 15:37
To: Doerr, Martin <martin.doerr at sap.com>; hotspot-runtime-dev at openjdk.java.net; Gustavo Romero <gromero at linux.vnet.ibm.com>
Subject: RE: RFR(S): 8216376: [PPC64] Possibly unreliable stack frame resizing in template interpreter

Hi Martin, 

I had a look at your change. 
To me, it looks correct, and I also understand that it makes the
frame resizing more stable. 

On the other hand, it adds dependent instructions ld/st to 
each call, where before just a register was moved. 
This might eat up some of the performance benefits of the 
frame resizing.  As the backlink is checked in assertions, 
do you really think this is worth while?  Shouldn't we just 
harden the assertions if necessary?

Best regards,
  Goetz.



> -----Original Message-----
> From: Doerr, Martin
> Sent: Dienstag, 8. Januar 2019 18:43
> To: hotspot-runtime-dev at openjdk.java.net; Gustavo Romero
> <gromero at linux.vnet.ibm.com>; Lindenmaier, Goetz
> <goetz.lindenmaier at sap.com>
> Subject: RFR(S): 8216376: [PPC64] Possibly unreliable stack frame resizing in
> template interpreter
> 
> Hi,
> 
> 
> 
> we recently noticed stack corruption while testing JDK-8216060. The issue
> was not directly in the new code, but it didn't work with the current handling
> of the interpreter stack frames which is very error-prone at a few places.
> 
> I'd like to improve these places. At least one of them even seems to be
> unreliable in the current implementation.
> 
> 
> 
> Bug with some more background information:
> 
> https://bugs.openjdk.java.net/browse/JDK-8216376
> 
> 
> 
> My proposal to fix it:
> 
> http://cr.openjdk.java.net/~mdoerr/8216376_PPC64_frame_resizing/webrev
> .00/
> 
> 
> 
> Please review.
> 
> 
> 
> Best regards,
> 
> Martin
> 
>