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

Doerr, Martin martin.doerr at sap.com
Wed Jan 9 16:20:35 UTC 2019


Hi Götz,

thanks for the review.

Best regards,
Martin


-----Original Message-----
From: Lindenmaier, Goetz 
Sent: Mittwoch, 9. Januar 2019 15:52
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

OK, I understand. 

Reviewed. 

Best regards,
  Goetz.

> -----Original Message-----
> From: Doerr, Martin
> Sent: Mittwoch, 9. Januar 2019 15:50
> To: Lindenmaier, Goetz <goetz.lindenmaier 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 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
> >
> >



More information about the hotspot-runtime-dev mailing list