RFR 8222806: Inefficient String.replace in PathFileObject.toBinaryName

[John Rose]

I think it’s a slam dunk. The code for replace(String,String) is so full of branches another predictable branch won’t change the dynamics.  It’s already a large JIT method, so inlining won’t change significantly. 

Having special paths for special lengths in String is typical enough in that code. 

> On Apr 23, 2019, at 9:14 AM, Liam Miller-Cushon <cushon at google.com> wrote:
> 
> In the general case, String.replace is probably more likely to see longer arguments, and adding the additional logic and branches there may be less of a slam-dunk.