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

[Doerr, Martin]

Hi,

I'm fine with it, too.

Thanks and best regards,
Martin


> -----Original Message-----
> From: hotspot-compiler-dev <hotspot-compiler-dev-
> bounces at openjdk.java.net> On Behalf Of Tobias Hartmann
> Sent: Donnerstag, 7. Mai 2020 11:50
> To: Liu, Xin <xxinliu at amazon.com>; hotspot-compiler-
> dev at openjdk.java.net
> Subject: Re: RFR(S): 8022574: remove HaltNode code after uncommon trap
> calls
> 
> 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.syst
> em.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
> >
> >