On Tue, 25 Jun 2024 19:33:02 GMT, Naoto Sato wrote:
>> I did not mean to introduce a public API for this change (if we do, the fix
>> cannot be backported). I thought we could define a package private one, but
>> based on your observation, it may get messier... So I agree that falling
>> back
On Tue, 25 Jun 2024 19:33:02 GMT, Naoto Sato wrote:
> > So, considering all the information given, is it enough to start our new
> > review process? @naotoj @liach @justin-curtis-lu
>
> Well, I was suggesting the same buffer proxying for other Format classes than
> NumberFormat subclasses, suc
On Thu, 20 Jun 2024 18:58:27 GMT, Naoto Sato wrote:
>> lingjun-cg has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> 896: Performance regression of DecimalFormat.format
>
> I did not mean to introduce a public API for this change (if we
On Thu, 20 Jun 2024 18:58:27 GMT, Naoto Sato wrote:
>> lingjun-cg has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> 896: Performance regression of DecimalFormat.format
>
> I did not mean to introduce a public API for this change (if we
On Fri, 21 Jun 2024 02:10:59 GMT, lingjun-cg wrote:
> If do that ,there is some performance degradation.
Thanks for taking the time to do benchmarks. If that is the case, then lets
stick with the proxy solution then.
-
PR Comment: https://git.openjdk.org/jdk/pull/19513#issuecommen
On Thu, 20 Jun 2024 21:53:25 GMT, Justin Lu wrote:
> > It requires append(int), but the Appendable has no such method.
>
> If via `Appendable` we don't have access to `append(int)`, can we simply
> `append(String.valueOf(int))`. And similarly for `append(char[], int, int)`,
> can we `append(St
On Wed, 19 Jun 2024 02:05:28 GMT, lingjun-cg wrote:
> It requires append(int), but the Appendable has no such method.
If via `Appendable` we don't have access to `append(int)`, can we simply
`append(String.valueOf(int))`.
And similarly for `append(char[], int, int)`, can we
`append(String.valu
On Tue, 18 Jun 2024 10:00:33 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.
On Tue, 18 Jun 2024 10:00:33 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.
On Tue, 18 Jun 2024 10:00:33 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.
On Wed, 19 Jun 2024 02:12:01 GMT, lingjun-cg wrote:
>> src/java.base/share/classes/java/text/Format.java line 278:
>>
>>> 276: * {@code false} otherwise
>>> 277: */
>>> 278: boolean isInternalSubclass() {
>>
>> Since this is defined in Format, can we apply similar changes
On Tue, 18 Jun 2024 20:39:30 GMT, Justin Lu wrote:
>> lingjun-cg has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> 896: Performance regression of DecimalFormat.format
>
> src/java.base/share/classes/java/text/ChoiceFormat.java line 561
On Tue, 18 Jun 2024 20:36:52 GMT, Justin Lu wrote:
>> lingjun-cg has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> 896: Performance regression of DecimalFormat.format
>
> src/java.base/share/classes/java/text/Format.java line 278:
>
>
On Tue, 18 Jun 2024 10:00:33 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.
On Tue, 18 Jun 2024 10:00:33 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.
> ### 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
16 matches
Mail list logo
