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

[Tobias Hartmann]

Hi Xin,

looks good to me.

Best regards,
Tobias

On 07.05.20 08:53, Liu, Xin 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
> 
>