RFR(XS): Provide information when hitting a HaltNode for architectures other than x86

Liu, Xin xxinliu at amazon.com
Fri May 29 23:24:49 UTC 2020


Hello, 

Since JDK-8245986(aarch64) has been resolved, may I ask a sponsor to push this change? it's like last mile of JDK-8230552.
http://cr.openjdk.java.net/~xliu/8230552/02/webrev/

s390 has been reviewed by Martin.  Thank Volker and OSU, I verified the new stop() mechanism on a ppc64le host.

Thanks,
--lx

On 5/28/20, 3:03 AM, "Andrew Haley" <aph at redhat.com> wrote:

    CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.



    On 27/05/2020 21:09, Liu, Xin wrote:
    > Yes, it's better.  I compare two stacktraces and cframes in the previous stacktrace indeed disturb users from understanding their own problems.
    > I reviewed Andrew's webrev.  It looks good to me.

    > I am happy to see that you solve rscratch1 clobber problem in such
    > elegant way!

    Great, thanks.

    > Just one thing:  for this instruction emit_int64((intptr_t)msg),  can we safely say a pointer is always 64-bit on aarch64?

    That's a fair point. I'll change it: there's no need for that code to
    depend on pointer size.

    > According to arm document, in theory, aarch64 has the ILP32 data
    > model, but I don't think we ever use ILP32 before on aarch64.

    If anyone ever makes IPL32 work, we'll be happy to fix HotSpot to run
    on it.

    > http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dai0490a/ar01s01.html
    >
    > May I ask Andrew to sponsor my patch when you push JDK-8245986?
    > Now it become trivial.  http://cr.openjdk.java.net/~xliu/8230552/02/webrev/


    --
    Andrew Haley  (he/him)
    Java Platform Lead Engineer
    Red Hat UK Ltd. <https://www.redhat.com>
    https://keybase.io/andrewhaley
    EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671




More information about the hotspot-compiler-dev mailing list