On Mon, 22 Jul 2024 09:07:31 GMT, Severin Gehwolf wrote:
>> Jan Kratochvil has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Unify 4 copies of adjust_controller()
>
> src/hotspot/os/linux/cgroupUtil_linux.cpp line 64:
>
>> 62: return
> As discussed in offline meeting, the max stack and locals information are
> part of the code attribute and not meaningful for buffered code elements.
> Computation would be costly and these see no real usage during
> transformations. Thus, the proposed solution is to move these APIs to be
> C
On Mon, 29 Jul 2024 00:37:21 GMT, ExE Boss wrote:
>> Chen Liang has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains three additional
>> commits sinc
On Sun, 28 Jul 2024 02:39:23 GMT, Chen Liang wrote:
>> As discussed in offline meeting, the max stack and locals information are
>> part of the code attribute and not meaningful for buffered code elements.
>> Computation would be costly and these see no real usage during
>> transformations. Th
On Sun, 28 Jul 2024 15:52:03 GMT, Shaojin Wen wrote:
>> By removing the redundant code logic in
>> DateTimeFormatterBuilder$InstantPrinterParser#formatTo, the codeSize can be
>> reduced and the performance can be improved.
>
> Shaojin Wen has updated the pull request incrementally with one addi
> The current implementation of StringConcat is to mix the coder and length
> into a long. This operation will have some overhead for int/long/boolean
> types. We can separate the calculation of the coder from the calculation of
> the length, which can improve the performance in the scenario of
> By removing the redundant code logic in
> DateTimeFormatterBuilder$InstantPrinterParser#formatTo, the codeSize can be
> reduced and the performance can be improved.
Shaojin Wen has updated the pull request incrementally with one additional
commit since the last revision:
1. fix handle frac
On Sun, 28 Jul 2024 13:58:05 GMT, Shaojin Wen wrote:
>> The current implementation of StringConcat is to mix the coder and length
>> into a long. This operation will have some overhead for int/long/boolean
>> types. We can separate the calculation of the coder from the calculation of
>> the le
On Sun, 28 Jul 2024 13:58:05 GMT, Shaojin Wen wrote:
>> The current implementation of StringConcat is to mix the coder and length
>> into a long. This operation will have some overhead for int/long/boolean
>> types. We can separate the calculation of the coder from the calculation of
>> the le
> The current implementation of StringConcat is to mix the coder and length
> into a long. This operation will have some overhead for int/long/boolean
> types. We can separate the calculation of the coder from the calculation of
> the length, which can improve the performance in the scenario of
On Fri, 26 Jul 2024 15:32:18 GMT, Shaojin Wen wrote:
>> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java
>> line 3818:
>>
>>> 3816: }
>>> 3817: // add fraction
>>> 3818: if (fractionalDigits > 0) {
>>
>> This breaks the logic. `frac
On Fri, 26 Jul 2024 15:44:59 GMT, Shaojin Wen wrote:
>> By removing the redundant code logic in
>> DateTimeFormatterBuilder$InstantPrinterParser#formatTo, the codeSize can be
>> reduced and the performance can be improved.
>
> Shaojin Wen has updated the pull request incrementally with one addi
On Thu, 25 Jul 2024 23:36:02 GMT, Shaojin Wen wrote:
>> test/micro/org/openjdk/bench/java/lang/StringConcatGenerate.java line 47:
>>
>>> 45: @Measurement(iterations = 5, time = 1000, timeUnit =
>>> TimeUnit.MILLISECONDS)
>>> 46: @Fork(value = 3, jvmArgsAppend =
>>> "-Djava.lang.invoke.StringCo
> The current implementation of StringConcat is to mix the coder and length
> into a long. This operation will have some overhead for int/long/boolean
> types. We can separate the calculation of the coder from the calculation of
> the length, which can improve the performance in the scenario of
On Sat, 27 Jul 2024 23:08:36 GMT, Shaojin Wen wrote:
> Should mixer and prepend add the two types of Integer and Long? Now we need
> to do integer.toString and then concatenate, which leads to performance
> degradation.
I think the generic problem with specializing on types is that this leads
> The current implementation of StringConcat is to mix the coder and length
> into a long. This operation will have some overhead for int/long/boolean
> types. We can separate the calculation of the coder from the calculation of
> the length, which can improve the performance in the scenario of
On Thu, 25 Jul 2024 14:52:11 GMT, Shaojin Wen wrote:
>> The current implementation of StringConcat is to mix the coder and length
>> into a long. This operation will have some overhead for int/long/boolean
>> types. We can separate the calculation of the coder from the calculation of
>> the le
17 matches
Mail list logo
