On Fri, 12 Jul 2024 06:29:34 GMT, Julian Waters wrote:
> snprintf has been available for all officially and unofficially supported
> compilers for Windows, Visual Studio since version 2015 and gcc since, well,
> forever. snprintf is conforming to C99 since the start when compiling using
> gcc,
> snprintf has been available for all officially and unofficially supported
> compilers for Windows, Visual Studio since version 2015 and gcc since, well,
> forever. snprintf is conforming to C99 since the start when compiling using
> gcc, and 2015 when using Visual Studio. Since it conforms to
On Fri, 12 Jul 2024 19:18:09 GMT, Kim Barrett wrote:
> This should be using `os::snprintf` rather than `snprintf`. Rationale is in
> the comment here:
>
> https://github.com/openjdk/jdk/blob/1f6e106b45e5109224e13d70f1a40c9e666ec2ab/src/hotspot/share/runtime/os.cpp#L118-L126
>
> And yes, I know
On Sat, 13 Jul 2024 00:50:18 GMT, Shaojin Wen wrote:
>> Currently, about 25% of the time spent by the Integer.parseInt and
>> Long.parseLong methods is spent on the Character.digit method.
>>
>> The Character.digit method is common to all radixes. We can use a digit
>> method optimized for Lat
On Sat, 13 Jul 2024 00:50:18 GMT, Shaojin Wen wrote:
>> Currently, about 25% of the time spent by the Integer.parseInt and
>> Long.parseLong methods is spent on the Character.digit method.
>>
>> The Character.digit method is common to all radixes. We can use a digit
>> method optimized for Lat
On Sat, 13 Jul 2024 00:50:18 GMT, Shaojin Wen wrote:
>> Currently, about 25% of the time spent by the Integer.parseInt and
>> Long.parseLong methods is spent on the Character.digit method.
>>
>> The Character.digit method is common to all radixes. We can use a digit
>> method optimized for Lat
On Fri, 12 Jul 2024 07:39:11 GMT, SendaoYan wrote:
>> Hi all,
>> Currently, the testcase `test/jdk/tools/jlink/JLinkReproducibleTest.java`
>> doesn't receive jvm options from jtreg.
>> I think it's necessory to receive jvm options from jtreg.
>> Fix solution similar to
>> [JDK-8157850](https://
> Currently, about 25% of the time spent by the Integer.parseInt and
> Long.parseLong methods is spent on the Character.digit method.
>
> The Character.digit method is common to all radixes. We can use a digit
> method optimized for Latin1 encoding radix 10 to improve the performance of
> Integ
Currently, about 25% of the time spent by the Integer.parseInt and
Long.parseLong methods is spent on the Character.digit method.
The Character.digit method is common to all radixes. We can use a digit method
optimized for Latin1 encoding radix 10 to improve the performance of
Integer.parseInt
On Mon, 8 Jul 2024 14:14:02 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:
Please review the backport of #20145 onto jdk23, fixing 2 unnecessary and
erroneous links in the doc files.
-
Commit messages:
- Backport 5bc86f332986e3fffc1363f569029bb73a706064
Changes: https://git.openjdk.org/jdk/pull/20166/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&p
On Thu, 11 Jul 2024 20:55:29 GMT, Nizar Benalla wrote:
> Can I please get a review for this small change, the relative link to the
> stylesheet isn't needed as it wasn't used anyway in the generated HTML. The
> correct link to the stylesheet is already in the generated HTML.
>
> This is the di
On Thu, 11 Jul 2024 20:55:29 GMT, Nizar Benalla wrote:
> Can I please get a review for this small change, the relative link to the
> stylesheet isn't needed as it wasn't used anyway in the generated HTML. The
> correct link to the stylesheet is already in the generated HTML.
>
> This is the di
On Mon, 3 Jun 2024 18:00:35 GMT, Sean Gwizdak wrote:
>> Improve the speed of Method.hashCode by caching the hashcode on first use.
>> I've seen an application where Method.hashCode is a hot path, and this is a
>> fairly simple speedup. The memory overhead is low.
>>
>> This addresses issue
>
On Tue, 28 May 2024 17:25:34 GMT, Sean Gwizdak wrote:
> Improve the speed of Method.hashCode by caching the hashcode on first use.
> I've seen an application where Method.hashCode is a hot path, and this is a
> fairly simple speedup. The memory overhead is low.
>
> This addresses issue
> [JD
On Fri, 12 Jul 2024 13:57:23 GMT, Jorn Vernee wrote:
> This PR limits the number of cases in which we deoptimize frames when closing
> a shared Arena. The initial intent of this was to improve the performance of
> shared arena closure in cases where a lot of threads are accessing and
> closing
> This PR limits the number of cases in which we deoptimize frames when closing
> a shared Arena. The initial intent of this was to improve the performance of
> shared arena closure in cases where a lot of threads are accessing and
> closing shared arenas at the same time (see attached benchmark
> 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 Wed, 10 Jul 2024 21:46:36 GMT, Justin Lu wrote:
> Please review this PR, which is a backport of commit
> [861aefca](https://github.com/openjdk/jdk/commit/861aefcafacdc21459ef966307f52568e327fd49)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) mainline branch.
>
> This updates the IAN
On Fri, 12 Jul 2024 06:29:34 GMT, Julian Waters wrote:
> snprintf has been available for all officially and unofficially supported
> compilers for Windows, Visual Studio since version 2015 and gcc since, well,
> forever. snprintf is conforming to C99 since the start when compiling using
> gcc,
On Fri, 12 Jul 2024 15:58:56 GMT, Roman Kennke wrote:
>> src/hotspot/share/runtime/synchronizer.cpp line 390:
>>
>>> 388:
>>> 389: static bool useHeavyMonitors() {
>>> 390: #if defined(X86) || defined(AARCH64) || defined(PPC64) ||
>>> defined(RISCV64) || defined(S390)
>>
>> Why are those if-d
On Fri, 12 Jul 2024 12:08:15 GMT, Andrey Turbanov wrote:
>> Please review this PR, which is a backport of commit
>> [86b0cf25](https://github.com/openjdk/jdk/commit/86b0cf259fb3cbe3a1973151148e5d36c6a99d91)
>> from the [openjdk/jdk](https://git.openjdk.org/jdk) mainline branch.
>>
>> This chan
On Tue, 9 Jul 2024 20:43:06 GMT, Coleen Phillimore wrote:
>> Axel Boldt-Christmas has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Add JVMCI symbol exports
>> - Revert "More graceful JVMCI VM option interaction"
>>
>>This rever
On Fri, 12 Jul 2024 15:56:59 GMT, Roman Kennke wrote:
>> Axel Boldt-Christmas has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Update arguments.cpp
>
> src/hotspot/share/runtime/synchronizer.cpp line 390:
>
>> 388:
>> 389: static bool u
On Fri, 12 Jul 2024 05:57:30 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
>> l
On Mon, 3 Jun 2024 18:00:35 GMT, Sean Gwizdak wrote:
>> Improve the speed of Method.hashCode by caching the hashcode on first use.
>> I've seen an application where Method.hashCode is a hot path, and this is a
>> fairly simple speedup. The memory overhead is low.
>>
>> This addresses issue
>
On Fri, 12 Jul 2024 14:22:33 GMT, fabioromano1 wrote:
>> src/java.base/share/classes/java/math/MutableBigInteger.java line 2054:
>>
>>> 2052:
>>> 2053: rem.add(ONE);
>>> 2054: rem.subtract(twiceSqrt);
>>
>> Shouldn't these be `rem + twiceSqrt - 1`?
>
> No, becau
On Fri, 12 Jul 2024 14:55:19 GMT, fabioromano1 wrote:
>> In the paper `u` is called R'', so I'd rename it as `rpp` (for R prime
>> prime). Generally, the more the names in the code match the ones in the
>> paper, the easier it becomes to read the code with the paper at hand.
>>
>> Then you can
On Fri, 12 Jul 2024 14:42:33 GMT, Raffaello Giulietti
wrote:
>> Like `u_a0`? It is the most "mathematical" name that comes to my mind.
>
> In the paper `u` is called R'', so I'd rename it as `rpp` (for R prime
> prime). Generally, the more the names in the code match the ones in the
> paper, t
On Fri, 12 Jul 2024 14:20:23 GMT, fabioromano1 wrote:
>> Ok, but what should the name be?
>
> Like `u_a0`? It is the most "mathematical" name that comes to my mind.
In the paper `u` is called R'', so I'd rename it as `rpp` (for R prime prime).
Generally, the more the names in the code match the
On Fri, 12 Jul 2024 13:51:24 GMT, fabioromano1 wrote:
>> src/java.base/share/classes/java/math/MutableBigInteger.java line 1967:
>>
>>> 1965: MutableBigInteger[] sqrtRem = x.sqrtRemZimmermann(x.intLen,
>>> needRemainder);
>>> 1966:
>>> 1967: // Unnormalize
>>
>> This unnormali
On Fri, 12 Jul 2024 13:57:55 GMT, fabioromano1 wrote:
>> (Yes, I proved it to myself in this way.)
>>
>> A similar explanation should be in a comment in the code, not here. The
>> source of truth is the code, not the comments on GitHub ;-)
>
> I would keep zero as the only special case, so as n
This PR limits the number of cases in which we deoptimize frames when closing a
shared Arena. The initial intent of this was to improve the performance of
shared arena closure in cases where a lot of threads are accessing and closing
shared arenas at the same time (see attached benchmark), but u
On Fri, 5 Jul 2024 23:06:17 GMT, Shaojin Wen wrote:
> The current HexFormat defines an Enum to represent LowerCase and UpperCase
>
>
> class HexFormat {
> private enum Case {
> LOWERCASE,
> UPPERCASE
> }
> }
>
>
> This will cause the JVM to load one more class when it
On Fri, 12 Jul 2024 13:08:59 GMT, Raffaello Giulietti
wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Added comment on normalization in MutableBigInteger.sqrtRemZimmermann()
>
> src/java.base/share/classes/java/ma
On Fri, 12 Jul 2024 13:08:37 GMT, Raffaello Giulietti
wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Added comment on normalization in MutableBigInteger.sqrtRemZimmermann()
>
> src/java.base/share/classes/java/ma
On Fri, 12 Jul 2024 14:16:38 GMT, fabioromano1 wrote:
>> src/java.base/share/classes/java/math/MutableBigInteger.java line 2040:
>>
>>> 2038: sqrt.add(q);
>>> 2039:
>>> 2040: MutableBigInteger chunk = u;
>>
>> I don't get the need for `chunk`. It should be possible to use `u` d
On Wed, 10 Jul 2024 22:02:12 GMT, Shaojin Wen wrote:
>> The current HexFormat defines an Enum to represent LowerCase and UpperCase
>>
>>
>> class HexFormat {
>> private enum Case {
>> LOWERCASE,
>> UPPERCASE
>> }
>> }
>>
>>
>> This will cause the JVM to load one more c
On Fri, 12 Jul 2024 13:08:29 GMT, Raffaello Giulietti
wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Added comment on normalization in MutableBigInteger.sqrtRemZimmermann()
>
> src/java.base/share/classes/java/ma
On Fri, 12 Jul 2024 13:07:51 GMT, Raffaello Giulietti
wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Added comment on normalization in MutableBigInteger.sqrtRemZimmermann()
>
> src/java.base/share/classes/java/ma
On Fri, 12 Jul 2024 13:07:39 GMT, Raffaello Giulietti
wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Added comment on normalization in MutableBigInteger.sqrtRemZimmermann()
>
> src/java.base/share/classes/java/ma
On Fri, 12 Jul 2024 13:49:55 GMT, Raffaello Giulietti
wrote:
>> The proof has been made simply by exaustive experiment: for every long value
>> `s` in [0, 2^32) such that `x == s * s`, it is true that `s == (long)
>> Math.sqrt(x >= 0 ? x : x + 0x1p64)`. This can be verified directly by a Java
On Fri, 12 Jul 2024 13:07:02 GMT, Raffaello Giulietti
wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Added comment on normalization in MutableBigInteger.sqrtRemZimmermann()
>
> src/java.base/share/classes/java/ma
On Fri, 12 Jul 2024 13:43:29 GMT, fabioromano1 wrote:
>> src/java.base/share/classes/java/math/MutableBigInteger.java line 1941:
>>
>>> 1939:
>>> 1940: // Initial estimate is the square root of the unsigned
>>> long value.
>>> 1941: long s = (long) Math.sqrt(x > 0 ? x :
On Fri, 12 Jul 2024 13:06:46 GMT, Raffaello Giulietti
wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Added comment on normalization in MutableBigInteger.sqrtRemZimmermann()
>
> src/java.base/share/classes/java/ma
On Fri, 12 Jul 2024 13:06:35 GMT, Raffaello Giulietti
wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Added comment on normalization in MutableBigInteger.sqrtRemZimmermann()
>
> src/java.base/share/classes/java/ma
On Fri, 12 Jul 2024 13:28:14 GMT, fabioromano1 wrote:
>> src/java.base/share/classes/java/math/MutableBigInteger.java line 128:
>>
>>> 126: intLen = 2;
>>> 127: value[0] = hi;
>>> 128: value[1] = (int) val;
>>
>> Suggestion:
>>
>> value = new int
On Fri, 12 Jul 2024 13:04:42 GMT, Raffaello Giulietti
wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Added comment on normalization in MutableBigInteger.sqrtRemZimmermann()
>
> src/java.base/share/classes/java/ma
On Fri, 12 Jul 2024 11:57:56 GMT, Erik Österlund wrote:
> The runtime use of the Access API knows how to resolve an unknown oop ref
> strength using AccessBarrierSupport::resolve_unknown_oop_ref_strength.
> However, we do not have support for that in the C2 backend. In fact, it does
> not unde
On Mon, 8 Jul 2024 10:16:09 GMT, Jan Lahoda wrote:
>> 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 re
On Thu, 11 Jul 2024 06:54:27 GMT, Jan Kratochvil
wrote:
>> The testcase requires root permissions.
>>
>> Designed by Severin Gehwolf, implemented by Jan Kratochvil.
>
> Jan Kratochvil has updated the pull request with a new target base due to a
> merge or a rebase. The pull request now contai
On Tue, 9 Jul 2024 20:06:40 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 Fri, 12 Jul 2024 12:06:05 GMT, Andrew Haley wrote:
>> src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 343:
>>
>>> 341: const Register t3_owner = t3;
>>> 342: const ByteSize monitor_tag = in_ByteSize(UseObjectMonitorTable ? 0
>>> : checked_cast(markWord::monitor_value));
>>
> 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 Fri, 12 Jul 2024 10:54:23 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
>> l
On Fri, 12 Jul 2024 12:28:16 GMT, Jan Kratochvil
wrote:
> With #17198 and this updated patch I still get the a FAIL due to:
>
> ```
> [0.333s][trace][os,container] OSContainer::active_processor_count: 4
> ```
>
> But let's resolve it after #17198 gets final/approved.
Because the #17198 is inc
On Thu, 11 Jul 2024 16:46:13 GMT, Severin Gehwolf wrote:
>> 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
>> c
On Wed, 10 Jul 2024 22:08:47 GMT, Justin Lu wrote:
>Please review this PR, which is a backport of commit
>[86b0cf25](https://github.com/openjdk/jdk/commit/86b0cf259fb3cbe3a1973151148e5d36c6a99d91)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
This message is kind of confusin
On Fri, 12 Jul 2024 09:40:45 GMT, Roman Kennke wrote:
>> Axel Boldt-Christmas has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Update arguments.cpp
>
> src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 343:
>
>> 341: const R
On Fri, 12 Jul 2024 10:22:42 GMT, Aleksey Shipilev wrote:
> > The reason we did not do this before is that this is not a strong reference
> > store. Strong reference stores with a SATB collector will keep the referent
> > alive, which is typically the exact opposite of what a user wants when th
On Fri, 12 Jul 2024 09:53:11 GMT, Roman Kennke wrote:
> When you say 'This patch has been evaluated to be performance neutral when
> UseObjectMonitorTable is turned off (the default).' - what does the
> performance look like with +UOMT? How does it compare to -UOMT?
Most benchmarks are unaffec
On Fri, 12 Jul 2024 09:32:44 GMT, Roman Kennke wrote:
>> Axel Boldt-Christmas has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Update arguments.cpp
>
> src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 318:
>
>> 316:
>> 317:
> 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 Fri, 12 Jul 2024 10:16:13 GMT, Erik Österlund wrote:
> The reason we did not do this before is that this is not a strong reference
> store. Strong reference stores with a SATB collector will keep the referent
> alive, which is typically the exact opposite of what a user wants when they
> cl
On Thu, 11 Jul 2024 15:28:37 GMT, Aleksey Shipilev wrote:
> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native
> method for `Reference.clear`. The original patch skipped intrinsification of
> this method, because we thought `Reference.clear` is not on a performance
> s
On Fri, 12 Jul 2024 05:57:30 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
>> l
On Fri, 12 Jul 2024 05:57:30 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
>> l
Can I please get a review of this test-only change which proposes to fix the
test timeout reported in https://bugs.openjdk.org/browse/JDK-8334167?
The JBS issue has comments which explains what causes the timeout. The commit
in this PR addresses those issues by updating the test specific
`Class
On Wed, 3 Jul 2024 14:17:37 GMT, fabioromano1 wrote:
> This implementation of MutableBigInteger.leftShift(int) optimizes the current
> version, avoiding unnecessary copy of the MutableBigInteger's value content
> and performing the primitive shifting only in the original portion of the
> value
This implementation of MutableBigInteger.leftShift(int) optimizes the current
version, avoiding unnecessary copy of the MutableBigInteger's value content and
performing the primitive shifting only in the original portion of the value
array rather than in the value yet extended with trailing zero
On Tue, 9 Jul 2024 23:29:28 GMT, Chen Liang wrote:
>> `CompoundElement` already inherits `Iterable` and its `forEach(Consumer)`,
>> thus we can remove `Iterable elements()` and `forEachElements(Consumer)`.
>
> Chen Liang has updated the pull request incrementally with one additional
> commit si
On Fri, 12 Jul 2024 07:05:58 GMT, Jaikiran Pai wrote:
>> SendaoYan has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> make variable TOOL_VM_OPTIONS to private
>
> test/jdk/tools/jlink/JLinkReproducibleTest.java line 41:
>
>> 39: public cla
> Hi all,
> Currently, the testcase `test/jdk/tools/jlink/JLinkReproducibleTest.java`
> doesn't receive jvm options from jtreg.
> I think it's necessory to receive jvm options from jtreg.
> Fix solution similar to
> [JDK-8157850](https://bugs.openjdk.org/browse/JDK-8157850), the change has
> bee
On Mon, 17 Jun 2024 15:24:27 GMT, Weijun Wang wrote:
>> Make sure `pd` is always the same object when `getProtectionDomain0` is null.
>
> Weijun Wang has updated the pull request incrementally with one additional
> commit since the last revision:
>
> explain why the test is related to the fix
On Fri, 12 Jul 2024 07:05:34 GMT, Jaikiran Pai wrote:
> I'll run this change against our CI instance just to be sure this doesn't
> cause unexpected issues. I'll approve the PR once those runs complete.
Thanks.
-
PR Comment: https://git.openjdk.org/jdk/pull/19669#issuecomment-2224
On Wed, 12 Jun 2024 02:00:41 GMT, SendaoYan wrote:
> Hi all,
> Currently, the testcase `test/jdk/tools/jlink/JLinkReproducibleTest.java`
> doesn't receive jvm options from jtreg.
> I think it's necessory to receive jvm options from jtreg.
> Fix solution similar to
> [JDK-8157850](https://bugs.o
76 matches
Mail list logo
