Re: RFR: 8333396: Performance regression of DecimalFormat.format [v6]

2024-06-17 Thread Naoto Sato
On Mon, 17 Jun 2024 20:10:18 GMT, Chen Liang wrote: >> For StringBuf proxy, is it acceptible for us to introduce a new jdk.internal >> public interface (accessible only within java.base module) to expose common >> public methods in AbstractStringBuilder? We have public types extending or >> im

Re: RFR: 8333396: Performance regression of DecimalFormat.format [v6]

2024-06-17 Thread Chen Liang
On Mon, 17 Jun 2024 18:47:11 GMT, Chen Liang wrote: >> lingjun-cg has updated the pull request incrementally with one additional >> commit since the last revision: >> >> 896: Performance regression of DecimalFormat.format > > For StringBuf proxy, is it acceptible for us to introduce a new

Re: RFR: 8333396: Performance regression of DecimalFormat.format [v6]

2024-06-17 Thread Naoto Sato
On Mon, 17 Jun 2024 18:47:11 GMT, Chen Liang wrote: >> lingjun-cg has updated the pull request incrementally with one additional >> commit since the last revision: >> >> 896: Performance regression of DecimalFormat.format > > For StringBuf proxy, is it acceptible for us to introduce a new

Re: RFR: 8333396: Performance regression of DecimalFormat.format [v6]

2024-06-17 Thread Chen Liang
On Fri, 14 Jun 2024 03:19:48 GMT, lingjun-cg wrote: >> ### Performance regression of DecimalFormat.format >> From the output of perf, we can see the hottest regions contain atomic >> instructions. But when run with JDK 11, there is no such problem. The >> reason is the removed biased locking.

Re: RFR: 8333396: Performance regression of DecimalFormat.format [v6]

2024-06-13 Thread lingjun-cg
> ### Performance regression of DecimalFormat.format > From the output of perf, we can see the hottest regions contain atomic > instructions. But when run with JDK 11, there is no such problem. The reason > is the removed biased locking. > The DecimalFormat uses StringBuffer everywhere, and St