RFR(S): 8143817: C1: Platform dependent stack space not preserved for all runtime calls

[Doerr, Martin]

Hi,

I think this is a real bug even though it does not lead to errors on many platforms.
The c_calling_convention should be consulted when we call C.

Can anybody take a look, please?

Best regards,
  Martin


From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Doerr, Martin
Sent: Montag, 30. November 2015 15:22
To: hotspot-compiler-dev at openjdk.java.net
Subject: RFR(S): 8143817: C1: Platform dependent stack space not preserved for all runtime calls

Hi,

Runtime calls usually use the c_calling_convention to compute the layout of the stack frames.

Currently, C1 does not use c_calling_convention for runtime calls without arguments, e.g. for calling os::javaTimeNanos. Hence, the platform dependent out_preserve_stack_slots is not accounted for.
A possible way to fix this is implemented in this webrev:
http://cr.openjdk.java.net/~mdoerr/8143817_c1_runtime_call/webrev.00

These ones are the 3 callers of the respective function which don't call c_calling_convention:
    do_RuntimeCall(CAST_FROM_FN_PTR(address, TRACE_TIME_METHOD), 0, x);
    do_RuntimeCall(CAST_FROM_FN_PTR(address, os::javaTimeMillis), 0, x);
    do_RuntimeCall(CAST_FROM_FN_PTR(address, os::javaTimeNanos), 0, x);

I think it would be more error prone to call it in all of them. The parameter "expected_arguments" is always 0.
Would it be better to assert "expected_arguments == 0"?

SPARC also uses out_preserve_stack_slots. Is this problem also relevant for SPARC?

Best regards,
  Martin

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