RFR: JDK-8224963: Char-Byte Performance Enhancement

[Adam Farley8]

Hi Andrew,

x86 code is something I haven't touched in years, and while it's possible 
I could find a way to make the code generated by C2 faster, I consider it 
unlikely that I'll be better at it than the current C2 specialists in the 
community.

Thank you, and Vladmir, for your time. :)

Best Regards

Adam Farley 
IBM Runtimes


Andrew Dinn <adinn at redhat.com> wrote on 11/06/2019 10:50:20:

> From: Andrew Dinn <adinn at redhat.com>
> To: Adam Farley8 <adam.farley at uk.ibm.com>, Vladimir Ivanov 
> <vladimir.x.ivanov at oracle.com>
> Cc: hotspot-compiler-dev at openjdk.java.net
> Date: 11/06/2019 10:50
> Subject: Re: RFR: JDK-8224963: Char-Byte Performance Enhancement
> 
> Hi Adam,
> 
> On 11/06/2019 10:04, Adam Farley8 wrote:
> > Merely patching the class library code will not effect any performance
> > enhancement.
> > 
> > Quite the opposite. :)
> > 
> > The changes in the class library were designed to work in tandem with
> > some changes to the OpenJ9 JIT compiler, which is what accelerates
> > performance.
> > 
> > Naturally, investigating and sharing OpenJ9 logic is a bad idea due to
> > contamination, so we're stuck with investigating the CL changes to
> > identify any potential value to OpenJDK with Hotspot.
> 
> This seems a slightly odd way to go about arriving at an improvement in
> the generated code.
> 
> What you probably ought to do in order to make progress here -- and
> /without/ exposing any secrets about the J9 implementation -- is to take
> an assembly dump of the x86 code that is currently being generated and
> then identify some transformation to that x86 code which 1) brings it
> nearer to what J9 produces and/or 2) clearly improves performance (you
> appear to be assuming 1 and 2 go together here but that is not actually
> required). n.b. you could identify such a generated code transformation
> starting either from the existing Java source or from your modified Java
> source.
> 
> If you /can/ specify what the improved machine code needs to look like
> relative to the current code then it would be possible and, perhaps,
> relatively easy for someone who does understand the C2 compiler to
> determine whether there is a way to adopt this alternative
> code-generation strategy simply by tweaking the C2 compiler.
> 
> Of course, the alternative might be that effecting such a change in
> generated code would require major changes to C2 -- it might even be (as
> the Arkansas farmer says) that you can't get there from here. Whatever,
> proceeding as suggested above won't expose what J9 is doing and won't
> require you to know what C2 is doing.
> 
> regards,
> 
> 
> Andrew Dinn
> -----------
> Senior Principal Software Engineer
> Red Hat UK Ltd
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
> 

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20190613/76f8fd67/attachment.html>