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