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