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

[Liu, Xin]

Hi, Martin and Andrew, 

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!
Just one thing:  for this instruction emit_int64((intptr_t)msg),  can we safely say a pointer is always 64-bit on aarch64?    
According to arm document,  in theory, aarch64 has the ILP32 data model, but I don't think we ever use ILP32 before on aarch64.
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/

Thanks,
--lx
 

On 5/27/20, 7:13 AM, "Doerr, Martin" <martin.doerr at sap.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.



    Hi Xin,

    I think Andrew's trap based version will be much better. But I'll leave the AArch64 part up to other people.

    > Another thing is I don't understand what's the benefit to
    > use the signal handler for that.
    Shorter code in the code cache (signal handler takes care of saving registers), better hs_err file (includes registers and instructions at the point at which the signal occurred, better stack trace: no nasty C-frames).

    Best regards,
    Martin


    > -----Original Message-----
    > From: Liu, Xin <xxinliu at amazon.com>
    > Sent: Mittwoch, 27. Mai 2020 00:58
    > To: aph at redhat.com; Ningsheng Jian <ningsheng.jian at arm.com>; aarch64-
    > port-dev at openjdk.java.net
    > Cc: Doerr, Martin <martin.doerr at sap.com>; hotspot-compiler-
    > dev at openjdk.java.net
    > Subject: Re: RFR(XS): Provide information when hitting a HaltNode for
    > architectures other than x86
    >
    > Hi,
    >
    > I make a new revision of JDK-8230552. May I ask the arm reviewers to take a
    > look?
    > http://cr.openjdk.java.net/~xliu/8230552/01/webrev/
    >
    > I haven't made aarch64 stop() uses the trap mechanism because it deserves
    > a standalone JBS.  Another thing is I don't understand what's the benefit to
    > use the signal handler for that.
    >
    > I do manage to reduce stop() code size per Ningsheng's request.  It avoids
    > from generating pusha if ShowMessageBoxOnError is off (default). It still acts
    > as expect no matter ShowMessageBoxOnError is set or not.  Since we now
    > have got rid of the HaltNode right after Uncommon_trap callnode in release
    > build, I don't think code bloat is an issue anymore.
    >
    > Thanks,
    > --lx
    >
    >
    >
    > On 5/6/20, 1:19 AM, "aph at redhat.com" <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 5/6/20 8:25 AM, Liu, Xin wrote:
    >     >     Currently in AArch64 MacroAssembler::stop(), it will generate many
    >     >     register saving instructions by pusha() before calling to debug64(). But
    >     >     I think debug64() only uses the regs[] and pc arguments when
    >     >     ShowMessageBoxOnError is on. Maybe we should at least only do the
    > saving
    >     >     and pc arg passing when ShowMessageBoxOnError is on in
    >     >     MacroAssembler::stop(), as what x86 does in
    > macroAssembler_x86.cpp?
    >
    >     Maybe we should think about a better way to do it. All we have
    >     to do, after all, is put the reason into, say, r8, and execute
    >     a trap. We don't need to push and pop anything because the trap
    >     handler will do that.
    >
    >     --
    >     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
    >