On Mon, 8 Jul 2024 17:31:53 GMT, Justin Lu wrote:
> I believe the `static MessageFormat.format(...` also has similar incorrect
> "this is equivalent ..." wording, if you could please include that as well. I
> think we should also rename the issue (and CSR) as well since the scope has
> changed
> ### 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, 8 Jul 2024 20:32:52 GMT, Joe Darcy wrote:
>> Make well-behaved implementation expectations of Object.{toString, hashCode}
>> explicit.
>
> Joe Darcy has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Respond to review feedback.
Looks
On Sun, 12 May 2024 02:48:31 GMT, xiaotaonan wrote:
> Add API to access ZipEntry.extraAttributes
This pull request has been closed without being integrated.
-
PR: https://git.openjdk.org/jdk/pull/19204
On Tue, 4 Jun 2024 17:42:23 GMT, Liam Miller-Cushon wrote:
>> This change overrides mutator methods in the implementation returned by
>> `Map.of().entrySet()` to throw `UnsupportedOperationException`.
>
> Liam Miller-Cushon has updated the pull request with a new target base due to
> a merge or
On Mon, 8 Jul 2024 18:04:49 GMT, Alan Bateman wrote:
> Specifying that toString returns a non-null result is good. Specifying that
> the methods don't throw any exceptions, or an implSpec that the methods
> shouldn't throw is okay.
>
> I'm less sure about the proposed wording for resource usag
> Make well-behaved implementation expectations of Object.{toString, hashCode}
> explicit.
Joe Darcy has updated the pull request incrementally with one additional commit
since the last revision:
Respond to review feedback.
-
Changes:
- all: https://git.openjdk.org/jdk/pull/20
On Mon, 8 Jul 2024 19:12:37 GMT, Joe Darcy wrote:
> PS There are cases where cyclic structures are not supported, such as in
> java.util.Set:
There are algorithms that also don't support that:
/**
* Returns a hash code based on the "deep contents" of the specified
* array. If th
On Mon, 8 Jul 2024 19:01:04 GMT, Joe Darcy wrote:
> One tricky part of the implementation was making sure the stack trace output
> did cycle detection since there were various ways exceptions could end up
> referring to each other.
Yes, the tricky part was to "Guard against malicious overrides
On Mon, 8 Jul 2024 19:11:43 GMT, Pavel Rappo wrote:
>>> While I understand and agree with the intent, we have several exceptions in
>>> the OpenJDK itself.
>>>
>>> Circular structures that throw `StackOverflowError` on `hashCode()` and
>>> huge numbers that take 20-30 min to compute `toString(
On Mon, 8 Jul 2024 17:04:07 GMT, Raffaello Giulietti
wrote:
> While I understand and agree with the intent, we have several exceptions in
> the OpenJDK itself.
>
> Circular structures that throw `StackOverflowError` on `hashCode()` and huge
> numbers that take 20-30 min to compute `toString()
On Thu, 4 Jul 2024 10:08:30 GMT, Kevin Walls wrote:
> There are two similarly names tests.
> Recently:
> JDK-8335124: com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java failed
> with CPU time out of expected range
> ...made a simple change to try and avoid noisy test failures. The same fix
On Mon, 8 Jul 2024 16:46:00 GMT, Joe Darcy wrote:
>> Make well-behaved implementation expectations of Object.{toString, hashCode}
>> explicit.
>
> Joe Darcy has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Update wording.
Specifying that t
On Fri, 10 Nov 2023 08:17:22 GMT, Per Minborg wrote:
>> This PR outlines a solution for making immutable maps `@ValueBased` by
>> removing cacheing of certain values in `AbstractMap`.
>>
>> By removing these caching fields in `AbstractMap`, we can make the immutable
>> maps `@ValueBased` and a
On Mon, 8 Jul 2024 02:32:17 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 Fri, 24 May 2024 15:32:09 GMT, Liam Miller-Cushon wrote:
> This change fixes a bug preventing javac from emitting
> 'compiler.warn.sun.proprietary' diagnostics if `--system` is set to a
> non-default value. The diagnostics are currently emitted for values of
> `--release`, and for the defau
On Tue, 4 Jun 2024 17:43:24 GMT, Liam Miller-Cushon wrote:
>> This change fixes a zip64 bug in the launcher that is prevent it from
>> reading the manifest of jars where the 'relative offset of local header'
>> field in the central directory entry is >4GB. As described in APPNOTE.TXT
>> 4.5.3,
On Mon, 8 Jul 2024 16:42:55 GMT, Joe Darcy wrote:
>> My understanding is the same. Personally, the wording reads unambiguously.
>> The words "circular" and "circularity" can be seen throughout codebase, in
>> similar contexts.
>>
>> FWIW, a simpler example can be constructed like this:
>>
>>
On Mon, 8 Jul 2024 09:55:27 GMT, Pavel Rappo wrote:
>> src/java.base/share/classes/java/lang/Object.java line 101:
>>
>>> 99: * implementation should not use excessive memory or time for its
>>> 100: * computations and should return a result for cyclic data
>>> 101: * structures.
> Make well-behaved implementation expectations of Object.{toString, hashCode}
> explicit.
Joe Darcy has updated the pull request incrementally with one additional commit
since the last revision:
Update wording.
-
Changes:
- all: https://git.openjdk.org/jdk/pull/20063/files
On Mon, 8 Jul 2024 03:06:17 GMT, Chen Liang wrote:
> Quick question about the violation of the "This is equivalent to" spec: Does
> our new implementation lead to any observable side effects that make the
> returned results or thrown exceptions different from that of `format(obj, new
> StringB
> When inflating a monitor the `ObjectMonitor*` is written directly over the
> `markWord` and any overwritten data is displaced into a displaced `markWord`.
> This is problematic for concurrent GCs which needs extra care or looser
> semantics to use this displaced data. In Lilliput this data als
On Mon, 8 Jul 2024 14:26:29 GMT, Matthias Baesken wrote:
> Hi Severin, sure ! I put it into our build/test setup .
Thanks!
-
PR Comment: https://git.openjdk.org/jdk/pull/20076#issuecomment-2214368557
On Mon, 8 Jul 2024 12:13:07 GMT, Axel Boldt-Christmas
wrote:
>> When inflating a monitor the `ObjectMonitor*` is written directly over the
>> `markWord` and any overwritten data is displaced into a displaced
>> `markWord`. This is problematic for concurrent GCs which needs extra care or
>> lo
On Mon, 8 Jul 2024 14:24:12 GMT, Severin Gehwolf wrote:
> @MBaesken Since you've noticed the failing test in your CI could you please
> verify the issue is gone with this? I don't have an Alpine Linux setup to
> easily test this exclusion. Thanks!
Hi Severin, sure ! I put it into our build/t
On Mon, 8 Jul 2024 14:19:21 GMT, Severin Gehwolf wrote:
> Please review this simple test fix to exclude the test from being run on an
> Alpine Linux system. Apparently default Alpine Linux systems don't have
> cgroups set up by default the way other distros do. More info on the bug. I
> propos
On Mon, 8 Jul 2024 14:19:21 GMT, Severin Gehwolf wrote:
> Please review this simple test fix to exclude the test from being run on an
> Alpine Linux system. Apparently default Alpine Linux systems don't have
> cgroups set up by default the way other distros do. More info on the bug. I
> propos
Please review this simple test fix to exclude the test from being run on an
Alpine Linux system. Apparently default Alpine Linux systems don't have cgroups
set up by default the way other distros do. More info on the bug. I propose to
not run the test on musl systems.
-
Commit mess
On Mon, 8 Jul 2024 13:57:20 GMT, Chen Liang wrote:
>> Adam Sotona has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fixed BootstrapMethodEntryImpl::computeHashCode
>
> src/java.base/share/classes/jdk/internal/classfile/impl/BootstrapMethod
> Class-File API constant pool implementation requires non-zero entry hash code.
> Unfortunately current implementation computes zero hash code for specific CP
> entries.
>
> This patch removes invalid and obsolete `AbstractPoolEntry::phiMix`
> calculation and assures all pool entries have non-z
On Mon, 8 Jul 2024 13:09:50 GMT, Adam Sotona wrote:
> Class-File API constant pool implementation requires non-zero entry hash code.
> Unfortunately current implementation computes zero hash code for specific CP
> entries.
>
> This patch removes invalid and obsolete `AbstractPoolEntry::phiMix`
On Sat, 29 Jun 2024 06:26:57 GMT, Alan Bateman wrote:
> I assume you'll create follow-up issues in JBS for the Class-Path attribute,
> improvement the usage/help output to replace the "Path"/"String" types.
I've filed: https://bugs.openjdk.org/browse/JDK-8335877 and
https://bugs.openjdk.org/br
Class-File API constant pool implementation requires non-zero entry hash code.
Unfortunately current implementation computes zero hash code for specific CP
entries.
This patch removes invalid and obsolete `AbstractPoolEntry::phiMix` calculation
and assures all pool entries have non-zero hash. A
On Fri, 5 Jul 2024 13:44:46 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 Tue, 18 Jun 2024 16:30:37 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 a li
On Mon, 8 Jul 2024 12:13:07 GMT, Axel Boldt-Christmas
wrote:
>> When inflating a monitor the `ObjectMonitor*` is written directly over the
>> `markWord` and any overwritten data is displaced into a displaced
>> `markWord`. This is problematic for concurrent GCs which needs extra care or
>> lo
> When inflating a monitor the `ObjectMonitor*` is written directly over the
> `markWord` and any overwritten data is displaced into a displaced `markWord`.
> This is problematic for concurrent GCs which needs extra care or looser
> semantics to use this displaced data. In Lilliput this data als
On Mon, 8 Jul 2024 10:58:29 GMT, Thomas Wuerthinger wrote:
> OK. Will there be a CSR or JEP for this?
There is no plan for this, nor should it be required. It’s an internal
implementation.
> When do you approximately expect this to land in main line?
ASAP. Compatibility for the field name i
On Wed, 3 Jul 2024 02:38:58 GMT, Chen Liang wrote:
> Please review this clean backport of #19981 onto JDK 23, fixing
> `StackMapGenerator` generating static methods with no declared local variable
> a max local of 1.
This pull request has now been integrated.
Changeset: 2f60d368
Author:Ch
On Mon, 8 Jul 2024 08:18:42 GMT, Axel Boldt-Christmas
wrote:
> When inflating a monitor the `ObjectMonitor*` is written directly over the
> `markWord` and any overwritten data is displaced into a displaced `markWord`.
> This is problematic for concurrent GCs which needs extra care or looser
>
On Wed, 3 Jul 2024 02:38:58 GMT, Chen Liang wrote:
> Please review this clean backport of #19981 onto JDK 23, fixing
> `StackMapGenerator` generating static methods with no declared local variable
> a max local of 1.
Marked as reviewed by asotona (Reviewer).
-
PR Review: https://
On Thu, 4 Jul 2024 18:04:27 GMT, Nizar Benalla wrote:
> Please review this simple doc only change.
> Some methods in ClassFile API were renamed recently as part of
> [JDK-8335290](https://bugs.openjdk.org/browse/JDK-8335290) and
> [JDK-8335110](https://bugs.openjdk.org/browse/JDK-8335110) and n
On Thu, 4 Jul 2024 18:04:27 GMT, Nizar Benalla wrote:
> Please review this simple doc only change.
> Some methods in ClassFile API were renamed recently as part of
> [JDK-8335290](https://bugs.openjdk.org/browse/JDK-8335290) and
> [JDK-8335110](https://bugs.openjdk.org/browse/JDK-8335110) and n
On Thu, 4 Jul 2024 18:04:27 GMT, Nizar Benalla wrote:
> Please review this simple doc only change.
> Some methods in ClassFile API were renamed recently as part of
> [JDK-8335290](https://bugs.openjdk.org/browse/JDK-8335290) and
> [JDK-8335110](https://bugs.openjdk.org/browse/JDK-8335110) and n
> For general pattern matching switches, the `SwitchBootstraps` class currently
> generates a cascade of `if`-like statements, computing the correct target
> case index for the given input.
>
> There is one special case which permits a relatively easy faster handling,
> and that is when all the
On Mon, 8 Jul 2024 09:39:32 GMT, Thomas Wuerthinger wrote:
> Is this change expected to require JVMCI and/or Graal JIT changes?
Support for `UseObjectMonitorTable` would require changes to Graal JIT.
(`UseObjectMonitorTable` is off by default).
Minimal support would be to call into the VM for
On Mon, 8 Jul 2024 09:33:54 GMT, Jaikiran Pai wrote:
>> Make well-behaved implementation expectations of Object.{toString, hashCode}
>> explicit.
>
> src/java.base/share/classes/java/lang/Object.java line 101:
>
>> 99: * implementation should not use excessive memory or time for its
>> 100
On Mon, 8 Jul 2024 08:18:42 GMT, Axel Boldt-Christmas
wrote:
> When inflating a monitor the `ObjectMonitor*` is written directly over the
> `markWord` and any overwritten data is displaced into a displaced `markWord`.
> This is problematic for concurrent GCs which needs extra care or looser
>
On Sun, 7 Jul 2024 20:20:30 GMT, Joe Darcy wrote:
> Make well-behaved implementation expectations of Object.{toString, hashCode}
> explicit.
src/java.base/share/classes/java/lang/Object.java line 101:
> 99: * implementation should not use excessive memory or time for its
> 100: * com
On Sun, 7 Jul 2024 20:20:30 GMT, Joe Darcy wrote:
> Make well-behaved implementation expectations of Object.{toString, hashCode}
> explicit.
Looks good.
-
Marked as reviewed by prappo (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/20063#pullrequestreview-2162781503
On Thu, 4 Jul 2024 18:04:27 GMT, Nizar Benalla wrote:
> Please review this simple doc only change.
> Some methods in ClassFile API were renamed recently as part of
> [JDK-8335290](https://bugs.openjdk.org/browse/JDK-8335290) and
> [JDK-8335110](https://bugs.openjdk.org/browse/JDK-8335110) and n
When inflating a monitor the `ObjectMonitor*` is written directly over the
`markWord` and any overwritten data is displaced into a displaced `markWord`.
This is problematic for concurrent GCs which needs extra care or looser
semantics to use this displaced data. In Lilliput this data also contai
On Fri, 5 Jul 2024 13:44:46 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
53 matches
Mail list logo
