[s390] RFR(XS): 8180659: micro-optimization in resize_frame_absolute()

[Doerr, Martin]

Hi Lutz,

nice change. Thanks for fixing writes below SP and also for improving readability.

I think the new pop_frame function should better be called e.g. pop_frame_and_restore_retPC because it performs this additional step in contrast to the other pop_frame function.

s390.ad needs a copyright update.

Besides that, it looks good to me. I can sponsor this change.

Best regards,
Martin



From: Schmidt, Lutz
Sent: Donnerstag, 29. Juni 2017 10:48
To: Doerr, Martin <martin.doerr at sap.com>; hotspot-compiler-dev at openjdk.java.net
Subject: Re: [s390] RFR(XS): 8180659: micro-optimization in resize_frame_absolute()

Hi Martin et al,

Finally, here is the expanded rework of my change. Doesn’t look big, but it took some time to make sure I didn’t miss places that need adaptation.

Bug:    https://bugs.openjdk.java.net/browse/JDK-8180659
Webrev: http://cr.openjdk.java.net/~lucy/webrevs/8180659.01/

Please have a look.

Thanks, Lutz

Dr. Lutz Schmidt | SAP JVM | PI  SAP CP Core | T: +49 (6227) 7-42834


On 01.06.2017, 16:58, "Schmidt, Lutz" <lutz.schmidt at sap.com<mailto:lutz.schmidt at sap.com>> wrote:

Hi Martin,

thank you for your comments! They triggered some deeper thoughts.

I could not find any written proof that it is ok to write outside the bounds given by the SP. The risk is minimal, though. You would need an external interrupt to hit the gap between the write and the SP update.

There is more than one code location affected. Doing it right will definitely blow up the fix size. There is not enough time right now: I will leave the office for vacation in an hour or so. I will resume working on the issue once I’m back (June 19th).

Best regards,
Lutz

On 29.05.2017, 12:58, "Doerr, Martin" <martin.doerr at sap.com<mailto:martin.doerr at sap.com>> wrote:

Hi Lutz,

thanks for providing the webrev.

Is it allowed to write to the stack before updating the SP?
I know that the PPC ABI allows this within a certain range, but I’m not aware of such an exception on s390x.

I’d also prefer separate functions instead of one with so many cases.
E.g. one function which copies the fp and one which takes a given fp like:
void MacroAssembler::resize_frame_absolute(Register newSP, Register fp) {
  assert_different_registers(newSP, fp, Z_SP);
  z_lgr(Z_SP, newSP);
  z_stg(fp, _z_abi(callers_sp), (newSP == Z_R0) ? Z_SP : newSP);
}

Thanks and best regards,
Martin


From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Schmidt, Lutz
Sent: Dienstag, 23. Mai 2017 12:47
To: hotspot-compiler-dev at openjdk.java.net<mailto:hotspot-compiler-dev at openjdk.java.net>
Subject: [10] [s390] RFR(XS): micro-optimization in resize_frame_absolute()

Dear all,

I would like to request reviews for this tiny, s390-only enhancement:
Bug:    https://bugs.openjdk.java.net/browse/JDK-8180659
Webrev: http://cr.openjdk.java.net/~lucy/webrevs/8180659.00/

Thank you!
Lutz

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20170629/d9dd090f/attachment-0001.html>