RFR: 8254807: Optimize startsWith() for String.substring() [v5]
Vladimir Ivanov
vladimir.x.ivanov at oracle.com
Mon Dec 14 23:30:51 UTC 2020
> I just want to say that it's an opener PR. I try sell a technique I called it "API simplification". From my observation, many java code can be more efficient if Java programmers just know "one more API". Even they’ve known, we can't blame them for the hindsight because sometimes certain patterns such as s.substring(1).startsWith("a") only emerge after deep inlining.
>
> Api simplification is here for help them out. I guess the real gain will be seen in this split case, even though it follows the same recipe here.
> https://github.com/navyxliu/StringFunc/blob/master/src/com/amazon/jdkteam/brownbag/SplitAndPick.java#L57
I'd be happy to help, but unfortunately I'm out of ideas how to solve
the general problem on the JIT-compiler level. It feels like JITs
operate on a lower-level than needed here. Bytecode rewriter looks like
a better fit, but it has an unfortunate limit on the operational scope
(per-method transformation) while JITs can partially relax it with
inlining.
> For the startsWith case, I did spend some time to research it. C2 can eliminate AllocateNode of newstring indeed, but I found c2 failed to eliminate two expensive nodes: AllocateArray and ArrayCopy for the underlying byte buffer. I don’t think this problem can be perfectly solved by EA and Scalar Replacement. Essentially, it’s redundancy and no new object should be allocated all all.
I suspect all the accesses into the intermediary char array should be
rewired to the original array before the copy can go away. (Also, debug
info can keep it alive unless you teach the runtime how to rematerialize
it on demand.)
Best regards,
Vladimir Ivanov
More information about the hotspot-compiler-dev
mailing list