RFR(S): 8022574: remove HaltNode code after uncommon trap calls

[Liu, Xin]

Thank you to review it. 
Yes, I will take care of the implementation stop(). 

Thanks,
--lx


On 5/7/20, 7:56 AM, "Volker Simonis" <volker.simonis at gmail.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,

    nice cleanup! And the space reduction for the CodeCache is not bad as well :)

    As this only removes the HaltNode after uncommon traps in the product
    build, we still have to take the code size of the HaltNode into
    account when you do 8230552 (and maybe improve the way how __stop
    works). But that can be done in the patch for 8230552.

    This looks good and is useful in itself.

    Thank you and best regards,
    Volker

    On Thu, May 7, 2020 at 9:02 AM Liu, Xin <xxinliu at amazon.com> wrote:
    >
    > Hi,
    >
    > Could you please review this patch?
    > JBS: https://bugs.openjdk.java.net/browse/JDK-8022574
    > Webrev: https://cr.openjdk.java.net/~xliu/8022574/00/webrev/
    >
    > This is the prerequisite of JDK-8230552. I agree with Martin's comment. I also want to remove the HaltNode after uncommon_trap.
    > https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-May/038104.html
    >
    > Because the HaltNode after uncommon_trap callnode also takes a special role in Matcher::Fixup_Save_On_Entry,
    > it's not easy to get rid of it.  I took another approach. I mark that HaltNode not reachable. As a result, backends can choose not to expand it.
    >
    > My assumption is that the control flow should never return from uncommon_trap because it must go to the interpreter.  HaltNode is rarely generated except this case. If this kind of HaltNode becomes dummy, we are safe to use "stop()" for the instruct "ShouldNotReachHere".  Stop() could provide more debugging information if C2 crashes due to HaltNode.
    >
    > I apply this optimization for all architectures except for SPARC.
    >
    > Currently, x86 generates 4 instruction, or 20 bytes for that HaltNode.
    > https://bugs.openjdk.java.net/browse/JDK-8022574?focusedCommentId=14336533&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14336533
    >
    > Usually, C2 generates a lot of uncommon trap calls for a variety of reasons. This patch can generate more compact code.
    > Eg. I observe the codeCache usage reduced even when java executes '-version'.
    > ./linux-x86_64-server-release/jdk/bin/java -Xcomp -XX:-TieredCompilation -XX:+PrintCodeCache -version
    > Before:
    > CodeCache: size=49152Kb used=4242Kb max_used=4478Kb free=44909Kb
    > After:
    > CodeCache: size=49152Kb used=3988Kb max_used=4474Kb free=45163Kb
    >
    > Testing:
    > I ran gtest and hotspot:tier1 on x86_64/linux and aarch64/linux.  No regression was identified.
    >
    > Thanks,
    > --lx
    >
    >