> By using the Class File API to dynamically generate a CompositePrinterParser,
> and defining DateTimePrinterParser[] printerParsers as a specific field, C2
> can do TypeProfile optimization.
>
> Since the CompositePrinterParser is generated based on the pattern, we can
> make the following op
On Mon, 3 Feb 2025 18:56:12 GMT, Chen Liang wrote:
>> Shaojin Wen has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> skip coder change
>
> src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 845:
>
>> 843: int spa
On Sun, 22 Oct 2023 17:26:52 GMT, Laurent Bourgès wrote:
>> * improved mixed insertion sort (makes whole sorting faster)
>> * introduced Radix which sort shows several times boost of performance and
>> has linear complexity instead of n*ln(n)
>> * improved merging sort for almost sorted data
>>
On Mon, 3 Feb 2025 22:18:51 GMT, Naoto Sato wrote:
> If we need more practical short name, "PST" might not be a bad choice.
I think use "Pacific Standard Time - PST" is a more practical chioce. The PR
has been updated.
-
PR Comment: https://git.openjdk.org/jdk/pull/23414#issuecomm
> Hi all,
> The JMH test
> "org.openjdk.bench.java.time.format.ZonedDateTimeFormatterBenchmark.parse"
> fails "java.time.format.DateTimeParseException: Text '2015:03:10:12:13:ECT'
> could not be parsed at index 17".
> The `ECT` standard for "America/Guayaquil" - "Ecuador Time", and since jdk23
On Mon, 3 Feb 2025 22:18:51 GMT, Naoto Sato wrote:
> most likely the failure was due to the removal of COMPAT locale provide
Yes. git bisect result shows that the failure was due to PR "8174269: Remove
COMPAT locale data provider from JDK"
And, use jdk22, the difference between '-Djava.locale
> The following code can reproduce the problem, writing out of bounds causes
> JVM Crash
>
>
>StringBuilder buf = new StringBuilder();
> buf.append('中');
>
> final CountDownLatch latch = new CountDownLatch(10);
> Runnable r = () -> {
> for (int i = 0; i < 1; i++) {
>
> By using the Class File API to dynamically generate a CompositePrinterParser,
> and defining DateTimePrinterParser[] printerParsers as a specific field, C2
> can do TypeProfile optimization.
>
> Since the CompositePrinterParser is generated based on the pattern, we can
> make the following op
On Tue, 3 Sep 2024 17:32:43 GMT, Naoto Sato wrote:
>> Shaojin Wen 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 nine additional
>> commits sin
> 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:
from @natoj
-
On Mon, 3 Feb 2025 07:49:21 GMT, SendaoYan wrote:
> Hi all,
> The JMH test
> "org.openjdk.bench.java.time.format.ZonedDateTimeFormatterBenchmark.parse"
> fails "java.time.format.DateTimeParseException: Text '2015:03:10:12:13:ECT'
> could not be parsed at index 17".
> The `ECT` standard for "Am
On Thu, 30 Jan 2025 14:36:28 GMT, Shaojin Wen wrote:
>> src/java.base/share/classes/jdk/internal/util/DateTimeHelper.java line 26:
>>
>>> 24: * questions.
>>> 25: */
>>> 26: package jdk.internal.util;
>>
>> Maybe `jdk.internal.time` would be appropriate.
>
> Currently, since we only have the
On Thu, 30 Jan 2025 15:11:28 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 Mon, 3 Feb 2025 07:49:21 GMT, SendaoYan wrote:
> Hi all,
> The JMH test
> "org.openjdk.bench.java.time.format.ZonedDateTimeFormatterBenchmark.parse"
> fails "java.time.format.DateTimeParseException: Text '2015:03:10:12:13:ECT'
> could not be parsed at index 17".
> The `ECT` standard for "Am
> (Also see `8319429: Resetting MXCSR flags degrades ecore`)
>
> This PR fixes two issues:
> - the original issue is a crash caused by `__ warn` corrupting the stack on
> Windows only
> - This issue also uncovered that -Xcheck:jni test cases were getting 65k
> lines of warning on HelloWorld (on
Hi Tesla,
In short, you can't. To write a local variable, the only way provided by the
ClassFile API is to create a java.lang.classfile.instruction.LocalVariable, and
send it to CodeBuilder::with, or just calling CodeBuilder::localVariable. The
LocalVariableInfo interface exists to faithfully re
I'm using classfile. It seems that the interface is sealed and either
implementations are not exported.
Best,
Tesla
> The following code can reproduce the problem, writing out of bounds causes
> JVM Crash
>
>
>StringBuilder buf = new StringBuilder();
> buf.append('中');
>
> final CountDownLatch latch = new CountDownLatch(10);
> Runnable r = () -> {
> for (int i = 0; i < 1; i++) {
>
> Adds `test.lib.Utils::createTempFileOfSize` to generate
> `test/jdk/com/sun/net/httpserver/docs` contents at runtime. This directory
> contains `largefile.txt` of size 2.6MiB showing up as the 4th largest file
> tracked by git:
>
>
> $ git ls-files | while read f; do echo -e $(stat -c %s "$f
> The following code can reproduce the problem, writing out of bounds causes
> JVM Crash
>
>
>StringBuilder buf = new StringBuilder();
> buf.append('中');
>
> final CountDownLatch latch = new CountDownLatch(10);
> Runnable r = () -> {
> for (int i = 0; i < 1; i++) {
>
> 3 finalizers in RMI code can be removed, as they do not perform meaningful
> cleanup.
>
> **`jdk.naming.rmi/share/classes/com/sun/jndi/rmi/registry/RegistryContext`**
>
> `RegistryContext.finalize()` just calls `close()`. The `close()` method does
> not perform any cleanup per se, but rather
On Mon, 3 Feb 2025 18:55:56 GMT, Vladimir Kozlov wrote:
> @jaikiran You need to get approval for JDK 24 backport.
Agreed. A approval request has already been raised
https://bugs.openjdk.org/browse/JDK-8349183?focusedId=14746841&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabp
On Mon, 3 Feb 2025 19:01:50 GMT, Justin Lu wrote:
>> Please review this PR which improves the performance of cut-over date
>> checking when the user supplies a properties override via the
>> `java.util.currency.data` sys prop. Replacing the `SimpleDateFormat` with a
>> _java.time_ alternative
> Adds `test.lib.Utils::createTempFileOfSize` to generate
> `test/jdk/com/sun/net/httpserver/docs` contents at runtime. This directory
> contains `largefile.txt` of size 2.6MiB showing up as the 4th largest file
> tracked by git:
>
>
> $ git ls-files | while read f; do echo -e $(stat -c %s "$f
On Mon, 3 Feb 2025 16:37:09 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which backs out the commit that was
>> introduced for https://bugs.openjdk.org/browse/JDK-8333893?
>>
>> The comment in the PR review of that issue
>> https://github.com/openjdk/jdk/pull/19626#issu
On Mon, 3 Feb 2025 18:58:57 GMT, Justin Lu wrote:
>> Please review this PR which improves the performance of cut-over date
>> checking when the user supplies a properties override via the
>> `java.util.currency.data` sys prop. Replacing the `SimpleDateFormat` with a
>> _java.time_ alternative
On Mon, 3 Feb 2025 18:05:51 GMT, Naoto Sato wrote:
>> src/java.base/share/classes/java/util/Currency.java line 1182:
>>
>>> 1180: private static boolean isPastCutoverDate(String cutOver) {
>>> 1181: return System.currentTimeMillis() >
>>> 1182: LocalDateTi
> Please review this PR which improves the performance of cut-over date
> checking when the user supplies a properties override via the
> `java.util.currency.data` sys prop. Replacing the `SimpleDateFormat` with a
> _java.time_ alternative has better performance. It should be noted that this
>
On Mon, 3 Feb 2025 18:41:44 GMT, Jaikiran Pai wrote:
> Can I please get a review of this backport of
> https://github.com/openjdk/jdk/pull/23420 into jdk24?
>
> This proposes to bring in those same backouts into `jdk24` to prevent the
> issue noted in that PR description. jdk24 is in rampdown
Can I please get a review of this backport of
https://github.com/openjdk/jdk/pull/23420 into jdk24?
This proposes to bring in those same backouts into `jdk24` to prevent the issue
noted in that PR description. jdk24 is in rampdown and this backport will
require an approval. A approval request h
This PR proposes to fix an Unsafe issue in a benchmark.
-
Commit messages:
- Add usage of Unsafe
Changes: https://git.openjdk.org/jdk/pull/23424/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23424&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8349238
Stats: 26 l
On Mon, 3 Feb 2025 12:47:15 GMT, Andrey Turbanov wrote:
>> Justin Lu has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> generalize format comment
>
> src/java.base/share/classes/java/util/Currency.java line 1182:
>
>> 1180: private
On Mon, 3 Feb 2025 16:37:09 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which backs out the commit that was
>> introduced for https://bugs.openjdk.org/browse/JDK-8333893?
>>
>> The comment in the PR review of that issue
>> https://github.com/openjdk/jdk/pull/19626#issu
On Mon, 3 Feb 2025 15:48:00 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which backs out the commit that was
> introduced for https://bugs.openjdk.org/browse/JDK-8333893?
>
> The comment in the PR review of that issue
> https://github.com/openjdk/jdk/pull/19626#issuecomm
On Mon, 3 Feb 2025 16:37:09 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which backs out the commit that was
>> introduced for https://bugs.openjdk.org/browse/JDK-8333893?
>>
>> The comment in the PR review of that issue
>> https://github.com/openjdk/jdk/pull/19626#issu
On Thu, 30 Jan 2025 11:03:43 GMT, Jatin Bhateja wrote:
>> Hi All,
>>
>> This patch adds C2 compiler support for various Float16 operations added by
>> [PR#22128](https://github.com/openjdk/jdk/pull/22128)
>>
>> Following is the summary of changes included with this patch:-
>>
>> 1. Detection
On Mon, 3 Feb 2025 17:43:12 GMT, Jaikiran Pai wrote:
> Thank you Claes and Chen for the reviews. tier1, tier2 and tier3 testing is
> nearing completion without any failures. Could one of you approve that it's
> OK to integrate this trivial backout without waiting for 24 hours (the review
> pro
On Mon, 3 Feb 2025 16:37:09 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which backs out the commit that was
>> introduced for https://bugs.openjdk.org/browse/JDK-8333893?
>>
>> The comment in the PR review of that issue
>> https://github.com/openjdk/jdk/pull/19626#issu
On Mon, 3 Feb 2025 16:37:09 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which backs out the commit that was
>> introduced for https://bugs.openjdk.org/browse/JDK-8333893?
>>
>> The comment in the PR review of that issue
>> https://github.com/openjdk/jdk/pull/19626#issu
On Mon, 3 Feb 2025 17:50:23 GMT, Shaojin Wen wrote:
> Can you wait for me for a while? I am looking for other solutions that do not
> require a fallback.
The updated fix/change (if any) doesn't have to be rushed and you can take
longer to work on it with additional help and reviews from others
On Mon, 3 Feb 2025 16:37:09 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which backs out the commit that was
>> introduced for https://bugs.openjdk.org/browse/JDK-8333893?
>>
>> The comment in the PR review of that issue
>> https://github.com/openjdk/jdk/pull/19626#issu
On Wed, 11 Dec 2024 18:17:43 GMT, Dan Heidinga wrote:
>> Yeah, I was just thinking whether something set from inside the VM which is
>> marked @Stable is constant-folded :)
>
> @viktorklang-ora `@Stable` is not about how the field was set, but about the
> JIT observing a non-default value at c
On Wed, 11 Dec 2024 15:06:54 GMT, Viktor Klang wrote:
>> I don't think this needs to be stable - finals in java.lang is trusted by
>> the JIT compiler.
>
> Yeah, I was just thinking whether something set from inside the VM which is
> marked @Stable is constant-folded :)
@viktorklang-ora `@Stab
On Wed, 11 Dec 2024 15:06:54 GMT, Viktor Klang wrote:
>> I don't think this needs to be stable - finals in java.lang is trusted by
>> the JIT compiler.
>
> Yeah, I was just thinking whether something set from inside the VM which is
> marked @Stable is constant-folded :)
I don't think @Stable w
On Wed, 11 Dec 2024 14:52:48 GMT, Chen Liang wrote:
>> src/java.base/share/classes/java/lang/Class.java line 1006:
>>
>>> 1004: private final transient int modifiers; // Set by the VM
>>> 1005:
>>> 1006: // package-private
>>
>> @coleenp Could this field be @Stable, or does that only
On Wed, 11 Dec 2024 10:24:03 GMT, Viktor Klang wrote:
>> The Class.getModifiers() method is implemented as a native method in
>> java.lang.Class to access a field that we've calculated when creating the
>> mirror. The field is final after that point. The VM doesn't need it
>> anymore, so ther
On Tue, 17 Dec 2024 15:54:48 GMT, ExE Boss wrote:
>> The Class.getModifiers() method is implemented as a native method in
>> java.lang.Class to access a field that we've calculated when creating the
>> mirror. The field is final after that point. The VM doesn't need it
>> anymore, so there's
On Mon, 9 Dec 2024 19:26:53 GMT, Coleen Phillimore wrote:
> The Class.getModifiers() method is implemented as a native method in
> java.lang.Class to access a field that we've calculated when creating the
> mirror. The field is final after that point. The VM doesn't need it anymore,
> so ther
On Mon, 9 Dec 2024 19:26:53 GMT, Coleen Phillimore wrote:
> The Class.getModifiers() method is implemented as a native method in
> java.lang.Class to access a field that we've calculated when creating the
> mirror. The field is final after that point. The VM doesn't need it anymore,
> so ther
On Wed, 11 Dec 2024 18:15:57 GMT, Dan Heidinga wrote:
>> The Class.getModifiers() method is implemented as a native method in
>> java.lang.Class to access a field that we've calculated when creating the
>> mirror. The field is final after that point. The VM doesn't need it
>> anymore, so ther
On Mon, 9 Dec 2024 19:26:53 GMT, Coleen Phillimore wrote:
> The Class.getModifiers() method is implemented as a native method in
> java.lang.Class to access a field that we've calculated when creating the
> mirror. The field is final after that point. The VM doesn't need it anymore,
> so ther
On Mon, 9 Dec 2024 21:35:42 GMT, ExE Boss wrote:
>> yes. it is needed.
>
> This is **C++**, so yes.
> Suggestion:
>
> macro(_modifiers_offset, k, vmSymbols::modifiers_name(),
> int_signature,false);
I see, there's a trailing semi somewhere in the expansion of this macro so it
On Mon, 9 Dec 2024 20:27:52 GMT, Coleen Phillimore wrote:
>> src/hotspot/share/classfile/javaClasses.cpp line 1504:
>>
>>> 1502: macro(_reflectionData_offset, k, "reflectionData",
>>> java_lang_ref_SoftReference_signature, false); \
>>> 1503: macro(_signers_offset, k,
On Mon, 9 Dec 2024 19:46:43 GMT, Chen Liang wrote:
>> The Class.getModifiers() method is implemented as a native method in
>> java.lang.Class to access a field that we've calculated when creating the
>> mirror. The field is final after that point. The VM doesn't need it
>> anymore, so there's
On Mon, 9 Dec 2024 19:26:53 GMT, Coleen Phillimore wrote:
> The Class.getModifiers() method is implemented as a native method in
> java.lang.Class to access a field that we've calculated when creating the
> mirror. The field is final after that point. The VM doesn't need it anymore,
> so ther
On Mon, 9 Dec 2024 19:26:53 GMT, Coleen Phillimore wrote:
> The Class.getModifiers() method is implemented as a native method in
> java.lang.Class to access a field that we've calculated when creating the
> mirror. The field is final after that point. The VM doesn't need it anymore,
> so ther
The Class.getModifiers() method is implemented as a native method in
java.lang.Class to access a field that we've calculated when creating the
mirror. The field is final after that point. The VM doesn't need it anymore,
so there's no real need for the jdk code to call into the VM to get it. Th
On Mon, 3 Feb 2025 16:37:09 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which backs out the commit that was
>> introduced for https://bugs.openjdk.org/browse/JDK-8333893?
>>
>> The comment in the PR review of that issue
>> https://github.com/openjdk/jdk/pull/19626#issu
On Mon, 3 Feb 2025 16:37:09 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which backs out the commit that was
>> introduced for https://bugs.openjdk.org/browse/JDK-8333893?
>>
>> The comment in the PR review of that issue
>> https://github.com/openjdk/jdk/pull/19626#issu
On Mon, 3 Feb 2025 17:04:33 GMT, Shaojin Wen wrote:
>> Jaikiran Pai has refreshed the contents of this pull request, and previous
>> commits have been removed. The incremental views will show differences
>> compared to the previous content of the PR. The pull request contains two
>> new commit
On Mon, 3 Feb 2025 16:37:09 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which backs out the commit that was
>> introduced for https://bugs.openjdk.org/browse/JDK-8333893?
>>
>> The comment in the PR review of that issue
>> https://github.com/openjdk/jdk/pull/19626#issu
On Mon, 3 Feb 2025 17:04:33 GMT, Shaojin Wen wrote:
> This concurrency problem also exists in the UTF16 scenario, so why only
> change to Latin1 here?
Do you mean there are additional commits that have been done in the JDK which
introduce a similar issue related to array writes beyond their li
On Mon, 28 Oct 2024 18:45:59 GMT, Tom Rodriguez wrote:
> Deoptimization with escape analysis can fail when trying to rematerialize
> objects as described in JDK-8227309. In this test this can happen in Xcomp
> mode in the framework of the test resulting in a test failure. Making the
> number
On Fri, 31 Jan 2025 22:18:32 GMT, Tom Rodriguez wrote:
>> Deoptimization with escape analysis can fail when trying to rematerialize
>> objects as described in JDK-8227309. In this test this can happen in Xcomp
>> mode in the framework of the test resulting in a test failure. Making the
>> nu
On Mon, 3 Feb 2025 16:37:09 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which backs out the commit that was
>> introduced for https://bugs.openjdk.org/browse/JDK-8333893?
>>
>> The comment in the PR review of that issue
>> https://github.com/openjdk/jdk/pull/19626#issu
> (Also see `8319429: Resetting MXCSR flags degrades ecore`)
>
> For performance, signaling flags (bottom 6 bits) are set by default in MXCSR.
> This PR fixes the Xcheck:jni comparison that is producing these copious
> warnings:
>
> OpenJDK 64-Bit Server VM warning: MXCSR changed by native JNI
> Can I please get a review of this change which backs out the commit that was
> introduced for https://bugs.openjdk.org/browse/JDK-8333893?
>
> The comment in the PR review of that issue
> https://github.com/openjdk/jdk/pull/19626#issuecomment-2628937397 explains
> what the issue is with the c
On Mon, 3 Feb 2025 14:31:28 GMT, Coleen Phillimore wrote:
>> This change removes the native call and injected field for ProtectionDomain
>> in the java.lang.Class instance, and moves the field to be declared in Java.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request with
> This change removes the native call and injected field for ProtectionDomain
> in the java.lang.Class instance, and moves the field to be declared in Java.
> Tested with tier1-4.
Coleen Phillimore has updated the pull request incrementally with one
additional commit since the last revision:
On Mon, 3 Feb 2025 14:31:28 GMT, Coleen Phillimore wrote:
>> This change removes the native call and injected field for ProtectionDomain
>> in the java.lang.Class instance, and moves the field to be declared in Java.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request with
Can I please get a review of this change which backs out the commit that was
introduced for https://bugs.openjdk.org/browse/JDK-8333893?
The comment in the PR review of that issue
https://github.com/openjdk/jdk/pull/19626#issuecomment-2628937397 explains what
the issue is with the change that w
On Mon, 3 Feb 2025 14:31:28 GMT, Coleen Phillimore wrote:
>> This change removes the native call and injected field for ProtectionDomain
>> in the java.lang.Class instance, and moves the field to be declared in Java.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request with
> This change removes the native call and injected field for ProtectionDomain
> in the java.lang.Class instance, and moves the field to be declared in Java.
> Tested with tier1-4.
Coleen Phillimore has updated the pull request with a new target base due to a
merge or a rebase. The incremental we
> By using the Class File API to dynamically generate a CompositePrinterParser,
> and defining DateTimePrinterParser[] printerParsers as a specific field, C2
> can do TypeProfile optimization.
>
> Since the CompositePrinterParser is generated based on the pattern, we can
> make the following op
On Mon, 3 Feb 2025 04:16:57 GMT, SendaoYan wrote:
>> Hi all,
>> Several JMH tests fails "Unrecognized VM option 'UseAVX=2'" on
>> linux-aarch64. The VM option '-XX:UseAVX=2' only support on x86_64 platform.
>> This PR add option '-XX:+IgnoreUnrecognizedVMOptions' to make test run
>> normally o
On Sat, 1 Feb 2025 14:37:44 GMT, SendaoYan wrote:
> Hi all,
> Several JMH tests fails "Unrecognized VM option 'UseAVX=2'" on linux-aarch64.
> The VM option '-XX:UseAVX=2' only support on x86_64 platform. This PR add
> option '-XX:+IgnoreUnrecognizedVMOptions' to make test run normally on non
>
On Fri, 17 Jan 2025 17:53:24 GMT, Galder Zamarreño wrote:
>> This patch intrinsifies `Math.max(long, long)` and `Math.min(long, long)` in
>> order to help improve vectorization performance.
>>
>> Currently vectorization does not kick in for loops containing either of
>> these calls because of
> By using the Class File API to dynamically generate a CompositePrinterParser,
> and defining DateTimePrinterParser[] printerParsers as a specific field, C2
> can do TypeProfile optimization.
>
> Since the CompositePrinterParser is generated based on the pattern, we can
> make the following op
On Thu, 23 Jan 2025 17:36:11 GMT, Matthias Ernst wrote:
>> Certain signatures for foreign function calls (e.g. HVA return by value)
>> require allocation of an intermediate buffer to adapt the FFM's to the
>> native stub's calling convention. In the current implementation, this buffer
>> is ma
On Sat, 1 Feb 2025 11:18:18 GMT, Matthias Ernst wrote:
>> Matthias Ernst has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> fix test under VThread factory
>
> Tried for a few hours to repro with various approaches, to no avail.
@mernst-git
On Mon, 3 Feb 2025 13:07:54 GMT, Shaojin Wen wrote:
>> src/java.base/share/classes/java/time/temporal/TemporalAccessor.java line
>> 327:
>>
>>> 325: * @return the year, from MIN_YEAR to MAX_YEAR
>>> 326: */
>>> 327: default int getYear() {
>>
>> The whole point of `TemporalAccess
On Mon, 3 Feb 2025 09:02:59 GMT, Stephen Colebourne
wrote:
> My comments refer to the outer parts of the PR. I haven't reviewed the class
> file generation part.
>
> With these changes, please ensure that the same field can be output twice.
> Not sure if any tests cover that.
>
> Thanks for
On Mon, 3 Feb 2025 07:59:02 GMT, Stephen Colebourne
wrote:
>> Shaojin Wen has updated the pull request incrementally with four additional
>> commits since the last revision:
>>
>> - typo
>> - bug fix, from @jodastephen
>> - bug fix, from @jodastephen
>> - typo
>
> src/java.base/share/class
> By using the Class File API to dynamically generate a CompositePrinterParser,
> and defining DateTimePrinterParser[] printerParsers as a specific field, C2
> can do TypeProfile optimization.
>
> Since the CompositePrinterParser is generated based on the pattern, we can
> make the following op
On Fri, 31 Jan 2025 19:46:37 GMT, Justin Lu wrote:
>> Please review this PR which improves the performance of cut-over date
>> checking when the user supplies a properties override via the
>> `java.util.currency.data` sys prop. Replacing the `SimpleDateFormat` with a
>> _java.time_ alternative
On Tue, 5 Nov 2024 08:28:10 GMT, Andrey Turbanov wrote:
> The field `com.sun.jndi.ldap.EventSupport#notifiers` is always accessed under
> `lock`. It means extra synchronization from `Hashtable` is not needed.
> Subtle difference in Hashtable vs Hashmap behavior is that Hashtable doesn't
> allow
On Mon, 3 Feb 2025 04:16:57 GMT, SendaoYan wrote:
>> Hi all,
>> Several JMH tests fails "Unrecognized VM option 'UseAVX=2'" on
>> linux-aarch64. The VM option '-XX:UseAVX=2' only support on x86_64 platform.
>> This PR add option '-XX:+IgnoreUnrecognizedVMOptions' to make test run
>> normally o
On Sun, 2 Feb 2025 13:20:39 GMT, Jaikiran Pai wrote:
>> Volkan Yazici has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove `assertFileContentsEqual()`
>
> test/lib/jdk/test/lib/Asserts.java line 623:
>
>> 621: * @throws IOExcepti
> Adds `test.lib.Utils::createTempFileOfSize` to generate
> `test/jdk/com/sun/net/httpserver/docs` contents at runtime. This directory
> contains `largefile.txt` of size 2.6MiB showing up as the 4th largest file
> tracked by git:
>
>
> $ git ls-files | while read f; do echo -e $(stat -c %s "$f
On Fri, 31 Jan 2025 10:29:53 GMT, Shaojin Wen wrote:
> By using the Class File API to dynamically generate a CompositePrinterParser,
> and defining DateTimePrinterParser[] printerParsers as a specific field, C2
> can do TypeProfile optimization.
>
> Since the CompositePrinterParser is generate
Hi all,
The JMH test
"org.openjdk.bench.java.time.format.ZonedDateTimeFormatterBenchmark.parse"
fails "java.time.format.DateTimeParseException: Text '2015:03:10:12:13:ECT'
could not be parsed at index 17".
The `ECT` standard for "America/Guayaquil" - "Ecuador Time", and since jdk23
the `ECT` Ti
91 matches
Mail list logo
