RFR(XXS): 8236228: clean up BarrierSet headers in c1_LIRAssembler

[Hohensee, Paul]

Lgtm. Seems very low risk to me too.

Paul

On 12/26/19, 7:06 PM, "hotspot-compiler-dev on behalf of Liu, Xin" <hotspot-compiler-dev-bounces at openjdk.java.net on behalf of xxinliu at amazon.com> wrote:

    Hi, Ningsheng, 
    Thank you for submitting the trial repo.  I got the result email and it has passed all 80 tests. 
    
    Here is the updated webrev.  I updated the reviewers.
    https://cr.openjdk.java.net/~xliu/8236228/01/webrev/
    
    This is a low-risk patch. As long as  we can compile it, it won't have any side-effect at runtime. 
    
    thanks,
    --lx
    
    On 12/24/19, 9:52 PM, "Ningsheng Jian" <Ningsheng.Jian at arm.com> wrote:
    
        Hi lx,
        
        I've submitted it for you:
        
        http://hg.openjdk.java.net/jdk/submit/rev/9d61b00d5982
        
        I've also verified aarch64 and arm build locally, and it looks fine. 
        
        Thanks,
        Ningsheng
        
        > -----Original Message-----
        > From: hotspot-compiler-dev <hotspot-compiler-dev-bounces at openjdk.java.net>
        > On Behalf Of Liu, Xin
        > Sent: Wednesday, December 25, 2019 4:57 AM
        > To: Vladimir Kozlov <vladimir.kozlov at oracle.com>; 'hotspot-compiler-
        > dev at openjdk.java.net' <hotspot-compiler-dev at openjdk.java.net>
        > Subject: Re: RFR(XXS): 8236228: clean up BarrierSet headers in c1_LIRAssembler
        > 
        > I update the subject and switch back the corporation email.  Sorry, I didn’t
        > realize that there’s code of conduct. I will pay more attention on it.
        > 
        > I validate the patch without PCH using --disable-precompiled-headers on both
        > x86_64 and aarch64. Both of them built well.
        > I still have difficulty to verify SPARC. I try the submit repo but I don’t have
        > permission to push an experimental branch.  May I ask a sponsor submit it on
        > behalf of me?
        > 
        > Thanks,
        > --lx
        > 
        > 
        > 
        > 
        > Hi Lx
        > 
        > First, when you post RFR, please, include bug id in email's Subject.
        > 
        > You can use jdk/submit testing to verify builds on SPARC. We are still building on
        > it, with warning.
        > Changes seems fine to me but make sure verify that it builds without PCH.
        > 
        > Regards,
        > Vladimir
        > 
        > On 12/20/19 9:24 AM, Liu Xin wrote:
        > > Martin，
        > >
        > > Thank you very much. May I know how to validate Sparc? I don't have
        > > any SPARC machine to access.
        > >
        > > Thanks,
        > > --lx
        > >
        > >
        > > On Fri, Dec 20, 2019, 7:05 AM Doerr, Martin
        > <martin.doerr at sap.com<mailto:martin.doerr at sap.com>> wrote:
        > >
        > >> Hi lx,
        > >>
        > >> PPC and s390 parts are ok.
        > >>
        > >> Best regards,
        > >> Martin
        > >>
        > >>
        > >>> -----Original Message-----
        > >>> From: hotspot-compiler-dev <hotspot-compiler-dev-
        > >>> bounces at openjdk.java.net<mailto:bounces at openjdk.java.net>> On Behalf
        > >>> Of Liu, Xin
        > >>> Sent: Freitag, 20. Dezember 2019 04:48
        > >>> To:
        > >>> 'hotspot-compiler-dev at openjdk.java.net<mailto:hotspot-compiler-dev at o
        > >>> penjdk.java.net>' <hotspot-compiler-
        > >>> dev at openjdk.java.net<mailto:dev at openjdk.java.net>>
        > >>> Subject: [DMARC FAILURE] RFR(XXS): clean up BarrierSet headers in
        > >>> c1_LIRAssembler
        > >>>
        > >>> Hi, Reviewers,
        > >>>
        > >>> Could you take a look at my webrev? I feel that those barrisetSet
        > >> interfaces
        > >>> have nothing with c1_LIRAssembler.
        > >>>
        > >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8236228
        > >>> Webrev: https://cr.openjdk.java.net/~xliu/8236228/00/webrev/
        > >>>
        > >>> I try to build on aarch64 and x86_64 and it’s fine.
        > >>>
        > >>> Thanks,
        > >>> --lx
        > >>
        > >>