> ### 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
> 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
> 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, 1 Jul 2024 19:17:50 GMT, Shaojin Wen wrote:
>> We need a String format solution with good performance. String Template was
>> once expected, but it has been removed. j.u.Formatter is powerful, but its
>> performance is not good enough.
>>
>> This PR implements a subset of j.u.Formatter
Trivial fix for the bug where `StackMapGenerator` is pre-allocating the locals
incorrectly, affecting static methods with 0 locals. `StackCounter` was not
affected.
-
Commit messages:
- 8335475: ClassBuilder incorrectly calculates max_locals in some cases
Changes: https://git.open
`Method.invoke` and `Constructor.newInstance` wraps `Error` in
`InvocationTargetException`, which is bug-prone for users. Worse, this is only
ambiguously mentioned in the API specification.
This patch proposes to explicitly mention that `InvocationTargetException`
wraps any throwable, and adds
On Mon, 1 Jul 2024 16:28:09 GMT, ExE Boss wrote:
>> j.u.Formatter supports args == null
>
> When `args == null` or `args.length == 0`, then the format string can still
> contain `%%` or `%n`, and those will be formatted to `"%"` and
> [`System.lineSeparator()`] respectively.
>
> [`System.lin
Clarify that only `Class` is returned for core reflection implementation, and
the return type is `Type` to support other implementations, such as ones
modeling unloaded or remote types.
-
Commit messages:
- 8250659: Clarify in ParameterizedType.getRawType() doc that only Class is
> We need a String format solution with good performance. String Template was
> once expected, but it has been removed. j.u.Formatter is powerful, but its
> performance is not good enough.
>
> This PR implements a subset of j.u.Formatter capabilities. The performance is
> good enough that it is
Clarify that `ParameterizedType.getOwnerType()` always return `null` in a few
scenarios.
-
Commit messages:
- 8306039: ParameterizedType.getOwnerType() documentation is incomplete about
null result
Changes: https://git.openjdk.org/jdk/pull/19977/files
Webrev: https://webrevs.ope
On Sat, 1 Jun 2024 11:49:39 GMT, Viktor Klang wrote:
> This PR improves the test failure output for the failing test case, and the
> underlying issue is likely going to be addressed by
> https://github.com/openjdk/jdk/pull/19131 /cc @DougLea
Marked as reviewed by psandoz (Reviewer).
-
On Mon, 1 Jul 2024 01:48:52 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 Sat, 29 Jun 2024 19:10:51 GMT, Shaojin Wen wrote:
>> src/java.base/share/classes/java/lang/StringFormat.java line 48:
>>
>>> 46: static String format(String format, Object... args) {
>>> 47: if (args != null) {
>>> 48: int off = format.indexOf('%');
>>
>> nit: instead
> 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
> `--
> Please review this PR which adds test support for systemd slices so that bugs
> like [JDK-8217338](https://bugs.openjdk.org/browse/JDK-8217338) can be
> verified. The added test, `SystemdMemoryAwarenessTest` currently passes on
> cgroups v1 and fails on cgroups v2 due to the way how
> [JDK-82
On Fri, 28 Jun 2024 19:43:36 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
> We need a String format solution with good performance. String Template was
> once expected, but it has been removed. j.u.Formatter is powerful, but its
> performance is not good enough.
>
> This PR implements a subset of j.u.Formatter capabilities. The performance is
> good enough that it is
On Mon, 1 Jul 2024 12:53:42 GMT, Shaojin Wen wrote:
>> We need a String format solution with good performance. String Template was
>> once expected, but it has been removed. j.u.Formatter is powerful, but its
>> performance is not good enough.
>>
>> This PR implements a subset of j.u.Formatter
> We need a String format solution with good performance. String Template was
> once expected, but it has been removed. j.u.Formatter is powerful, but its
> performance is not good enough.
>
> This PR implements a subset of j.u.Formatter capabilities. The performance is
> good enough that it is
On Wed, 26 Jun 2024 06:53:28 GMT, Adam Sotona wrote:
> Conversion of `java.lang.invoke` package to Class-File API is failing to
> execute method handles with specific type conversion requirements. Root cause
> is in the new `TypeConvertingMethodAdapter::primitiveTypeKindFromClass`
> implementa
On Wed, 26 Jun 2024 06:53:28 GMT, Adam Sotona wrote:
> Conversion of `java.lang.invoke` package to Class-File API is failing to
> execute method handles with specific type conversion requirements. Root cause
> is in the new `TypeConvertingMethodAdapter::primitiveTypeKindFromClass`
> implementa
On Wed, 26 Jun 2024 06:53:28 GMT, Adam Sotona wrote:
> Conversion of `java.lang.invoke` package to Class-File API is failing to
> execute method handles with specific type conversion requirements. Root cause
> is in the new `TypeConvertingMethodAdapter::primitiveTypeKindFromClass`
> implementa
On Fri, 28 Jun 2024 15:41:48 GMT, Severin Gehwolf wrote:
>> Please review this enhancement to the container detection code which allows
>> it to figure out whether the JVM is actually running inside a container
>> (`podman`, `docker`, `crio`), or with some other means that enforces
>> memory/c
On Mon, 11 Mar 2024 16:55:36 GMT, Severin Gehwolf wrote:
> Please review this enhancement to the container detection code which allows
> it to figure out whether the JVM is actually running inside a container
> (`podman`, `docker`, `crio`), or with some other means that enforces
> memory/cpu l
On Mon, 1 Jul 2024 06:18:55 GMT, Chen Liang wrote:
>> Shaojin Wen has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> code style
>
> As promising as the performance number is, I think we need to ensure two
> things:
> 1. Correctness: this p
On Wed, 26 Jun 2024 06:53:28 GMT, Adam Sotona wrote:
> Conversion of `java.lang.invoke` package to Class-File API is failing to
> execute method handles with specific type conversion requirements. Root cause
> is in the new `TypeConvertingMethodAdapter::primitiveTypeKindFromClass`
> implementa
On Fri, 28 Jun 2024 22:01:33 GMT, Chen Liang wrote:
> `ClassFile::transform` was initially `ClassModel::transform`, which
> transforms the receiver class model to a new class byte array. This
> functionality was in parallel with `ClassBuilder::transform`, which accepts a
> `ClassModel` and a `
27 matches
Mail list logo
