On Mon, 24 Jun 2024 04:25:45 GMT, Yude Lin wrote:
> [JDK-8318107](https://bugs.openjdk.org/browse/JDK-8318107) Un-ProblemListed
> LocaleProvidersRun and CalendarDataRegression, and
> [JDK-8288899](https://bugs.openjdk.org/browse/JDK-8288899) added them back.
> I'm guessing it's a mistake in re
On Fri, 21 Jun 2024 14:05:51 GMT, Kevin Walls wrote:
> Man page update for JDK-8327793 which marked jstatd as deprecated for removal
> in JDK 24.
Sorry this got left "pending" yesterday
src/jdk.jstatd/share/man/jstatd.1 line 49:
> 47: future release.
> 48: .PP
> 49: \f[B]Note:\f[R] This comma
> ### 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
On Mon, 24 Jun 2024 17:00:57 GMT, Naoto Sato wrote:
>> [JDK-8318107](https://bugs.openjdk.org/browse/JDK-8318107) Un-ProblemListed
>> LocaleProvidersRun and CalendarDataRegression, and
>> [JDK-8288899](https://bugs.openjdk.org/browse/JDK-8288899) added them back.
>> I'm guessing it's a mistake
On Mon, 24 Jun 2024 09:40:14 GMT, Christoph Langer wrote:
> Hi all,
>
> This pull request contains a backport of
> [JDK-8222884](https://bugs.openjdk.org/browse/JDK-8222884), commit
> [bd046d9b](https://github.com/openjdk/jdk/commit/bd046d9b9e79e4eea89c72af358961ef6e98e660)
> from the [openjd
On Mon, 17 Jun 2024 04:58:41 GMT, Shaojin Wen wrote:
>> The current versions of FloatToDecimal and DoubleToDecimal allocate
>> additional objects. Reducing these allocations can improve the performance
>> of Float/Double.toString and AbstractStringBuilder's append(float/double).
>>
>> This pat
On Fri, 21 Jun 2024 07:25:27 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 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 Sun, 16 Jun 2024 21:25:42 GMT, Claes Redestad wrote:
>> Shaojin Wen has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> code format
>
> Just suggesting some improvements
All suggestions have been fixed, can this PR be integrated? @cl4es
On Mon, 24 Jun 2024 22:11:55 GMT, Richard Reingruber wrote:
>> After JDK-8294960 is java.lang.invoke.ClassSpecializer using lamdas for code
>> generation and unfortunately it causes StackOverflow on BigEndian platforms.
>>
>> This patch converts all lambdas in ClassSpecializer into anonymous in
> I have implemented the Zimmermann's square root algorithm, available in works
> [here](https://inria.hal.science/inria-00072854/en/) and
> [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root).
>
> The algorithm is proved to be asymptotically faster than the New
On Mon, 24 Jun 2024 16:01:41 GMT, Adam Sotona wrote:
> After JDK-8294960 is java.lang.invoke.ClassSpecializer using lamdas for code
> generation and unfortunately it causes StackOverflow on BigEndian platforms.
>
> This patch converts all lambdas in ClassSpecializer into anonymous inner
> clas
On Fri, 21 Jun 2024 14:24:26 GMT, Hamlin Li wrote:
> Hi,
> Can you help to review this patch?
> Thanks!
>
> This is similar with previous JDK-8334396.
> Added some tests.
>
> ### Test
>
> | Tests | Scores | Errors | Unit
> -- | -- | -- | -- | --
> Intrinsic, +zbb, +rvv | Characters.reverseBy
> I have implemented the Zimmermann's square root algorithm, available in works
> [here](https://inria.hal.science/inria-00072854/en/) and
> [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root).
>
> The algorithm is proved to be asymptotically faster than the New
On Mon, 24 Jun 2024 16:01:41 GMT, Adam Sotona wrote:
> After JDK-8294960 is java.lang.invoke.ClassSpecializer using lamdas for code
> generation and unfortunately it causes StackOverflow on BigEndian platforms.
>
> This patch converts all lambdas in ClassSpecializer into anonymous inner
> clas
On Mon, 24 Jun 2024 04:25:45 GMT, Yude Lin wrote:
> [JDK-8318107](https://bugs.openjdk.org/browse/JDK-8318107) Un-ProblemListed
> LocaleProvidersRun and CalendarDataRegression, and
> [JDK-8288899](https://bugs.openjdk.org/browse/JDK-8288899) added them back.
> I'm guessing it's a mistake in re
On Sun, 23 Jun 2024 19:03:38 GMT, fabioromano1 wrote:
>> I have implemented the Zimmermann's square root algorithm, available in
>> works [here](https://inria.hal.science/inria-00072854/en/) and
>> [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root).
>>
>> The
On Mon, 24 Jun 2024 04:25:45 GMT, Yude Lin wrote:
> [JDK-8318107](https://bugs.openjdk.org/browse/JDK-8318107) Un-ProblemListed
> LocaleProvidersRun and CalendarDataRegression, and
> [JDK-8288899](https://bugs.openjdk.org/browse/JDK-8288899) added them back.
> I'm guessing it's a mistake in re
Hi all,
After [JDK-8294960](https://bugs.openjdk.org/browse/JDK-8294960), the
footprint memory usage increased significantly when run the testcase with
-Xcomp jvm options, then cause the testcase was killed by docker by OOM.
Maybe the footprint memory usage increased was inevitable, so I thin
After JDK-8294960 is java.lang.invoke.ClassSpecializer using lamdas for code
generation and unfortunately it causes StackOverflow on BigEndian platforms.
This patch converts all lambdas in ClassSpecializer into anonymous inner
classes.
Please review and test on a BigEndian platform.
Thanks,
Ad
> Please review this patch which adds a jlink mode to the JDK which doesn't
> need the packaged modules being present. A.k.a run-time image based jlink.
> Fundamentally this patch adds an option to use `jlink` even though your JDK
> install might not come with the packaged modules (directory `jm
On Mon, 24 Jun 2024 12:57:39 GMT, Jorn Vernee wrote:
>> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
>> code that accesses native functionality. Currently this includes `native`
>> method declarations, and methods marked with `@Restricted`.
>>
>> The tool accepts
On Sat, 22 Jun 2024 00:26:51 GMT, Chen Liang wrote:
> Please review this clean backport of #19708, to make javap recover and
> continue after encountering undefined access flag bits set while still
> exiting with a code of error, allowing it to error against improper bits
> while still providi
On Fri, 21 Jun 2024 14:05:51 GMT, Kevin Walls wrote:
> Man page update for JDK-8327793 which marked jstatd as deprecated for removal
> in JDK 24.
I assume we should hold off reviewing until the warning and the experiment note
are combined.
-
PR Comment: https://git.openjdk.org/jd
> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
> code that accesses native functionality. Currently this includes `native`
> method declarations, and methods marked with `@Restricted`.
>
> The tool accepts a list of class path and module path entries through
> `--
On Sat, 22 Jun 2024 00:26:51 GMT, Chen Liang wrote:
> Please review this clean backport of #19708, to make javap recover and
> continue after encountering undefined access flag bits set while still
> exiting with a code of error, allowing it to error against improper bits
> while still providi
On Mon, 24 Jun 2024 09:40:14 GMT, Christoph Langer wrote:
> Hi all,
>
> This pull request contains a backport of
> [JDK-8222884](https://bugs.openjdk.org/browse/JDK-8222884), commit
> [bd046d9b](https://github.com/openjdk/jdk/commit/bd046d9b9e79e4eea89c72af358961ef6e98e660)
> from the [openjd
On Sun, 23 Jun 2024 15:11:52 GMT, SendaoYan wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [1b1dba80](https://github.com/openjdk/jdk/commit/1b1dba8082969244effa86ac03c6053b3b0ddc43)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>
> The commit being
On Sun, 23 Jun 2024 15:11:52 GMT, SendaoYan wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [1b1dba80](https://github.com/openjdk/jdk/commit/1b1dba8082969244effa86ac03c6053b3b0ddc43)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>
> The commit being
On Sun, 23 Jun 2024 15:11:52 GMT, SendaoYan wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [1b1dba80](https://github.com/openjdk/jdk/commit/1b1dba8082969244effa86ac03c6053b3b0ddc43)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>
> The commit being
Hi all,
This pull request contains a backport of
[JDK-8222884](https://bugs.openjdk.org/browse/JDK-8222884), commit
[bd046d9b](https://github.com/openjdk/jdk/commit/bd046d9b9e79e4eea89c72af358961ef6e98e660)
from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
The commit being backpo
On Sun, 23 Jun 2024 15:11:52 GMT, SendaoYan wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [1b1dba80](https://github.com/openjdk/jdk/commit/1b1dba8082969244effa86ac03c6053b3b0ddc43)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>
> The commit being
On Sun, 23 Jun 2024 06:32:50 GMT, Hannes Greule wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [72ca7baf](https://github.com/openjdk/jdk/commit/72ca7bafcd49a98c1fe09da72e4e47683f052e9d)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>
> The commit be
On Fri, 21 Jun 2024 15:52:44 GMT, Chen Liang wrote:
> `ClassReader.readXxxEntry` were added before we had generic, type-aware
> `readEntry` and `readEntryOrNull` APIs (#19330). We should remove these
> specialized versions in favor of the generic version to reduce API bloating.
Looks good to m
34 matches
Mail list logo