On Fri, 19 Apr 2024 19:21:13 GMT, Jonathan Gibbons wrote:
>> Please review a set of updates to clean up use of `/**` comments in the
>> vicinity of declarations.
>>
>> There are various categories of update:
>>
>> * "Box comments" beginning with `/**`
>> * Misplaced doc comments before
On Fri, 19 Apr 2024 19:21:13 GMT, Jonathan Gibbons wrote:
>> Please review a set of updates to clean up use of `/**` comments in the
>> vicinity of declarations.
>>
>> There are various categories of update:
>>
>> * "Box comments" beginning with `/**`
>> * Misplaced doc comments before
On Mon, 22 Apr 2024 19:49:44 GMT, Brian Burkhalter wrote:
>> Prevent blocking due to a carrier thread not being released when
>> `ByteArrayOutputStream.writeTo` is invoked from a virtual thread.
>
> Brian Burkhalter has updated the pull request incrementally with one
> additional commit since
> Classes in the `java.lang.ref` package would benefit from an update to bring
> the spec in line with how the VM already behaves. The changes would focus on
> _happens-before_ edges at some key points during reference processing.
>
> A couple key things we want to be able to say are:
> -
> Re-write the IndexOf code without the use of the pcmpestri instruction, only
> using AVX2 instructions. This change accelerates String.IndexOf on average
> 1.3x for AVX2. The benchmark numbers:
>
>
> BenchmarkScore
> Latest
On Mon, 22 Apr 2024 18:44:33 GMT, Naoto Sato wrote:
> Upgrading the CLDR to version 45.0. We now have versions specified in the
> javadoc (`LocaleServiceProvider`), a corresponding CSR has also been drafted.
LGTM; `LocaleServiceProvider` displays correct CLDR version (45), and Italian
compact
On Mon, 22 Apr 2024 18:44:33 GMT, Naoto Sato wrote:
> Upgrading the CLDR to version 45.0. We now have versions specified in the
> javadoc (`LocaleServiceProvider`), a corresponding CSR has also been drafted.
Marked as reviewed by joehw (Reviewer).
-
PR Review:
> Prevent blocking due to a carrier thread not being released when
> `ByteArrayOutputStream.writeTo` is invoked from a virtual thread.
Brian Burkhalter has updated the pull request incrementally with one additional
commit since the last revision:
Correct ID in test @bug tag
-
Prevent blocking due to a carrier thread not being released when
`ByteArrayOutputStream.writeTo` is invoked from a virtual thread.
-
Commit messages:
- 8330748: ByteArrayOutputStream.writeTo(OutputStream) pins carrier
Changes: https://git.openjdk.org/jdk/pull/18901/files
Webrev:
On Fri, 19 Apr 2024 19:39:09 GMT, Sonia Zaldana Calles
wrote:
>> Hi folks,
>>
>> This PR aims to fix
>> [JDK-8329581](https://bugs.openjdk.org/browse/JDK-8329581).
>>
>> I think the regression got introduced in
>> [JDK-8315458](https://bugs.openjdk.org/browse/JDK-8315458).
>>
>> In the
Upgrading the CLDR to version 45.0. We now have versions specified in the
javadoc (`LocaleServiceProvider`), a corresponding CSR has also been drafted.
-
Commit messages:
- .md files
- release-45
- Fix tests for CLDR-17482 Fix million compact number issue in Italian
-
On Mon, 22 Apr 2024 12:45:53 GMT, Alan Bateman wrote:
>> This change drops the adjustments to the virtual thread scheduler's target
>> parallelism when virtual threads do file operations on files that are opened
>> for buffered I/O. These operations are usually just too short to have any
>>
On Mon, 22 Apr 2024 17:38:59 GMT, Jonathan Gibbons wrote:
> The document [How to Write Doc Comments for the Javadoc
> Tool](https://www.oracle.com/uk/technical-resources/articles/java/javadoc-tool.html)
> is depressingly obsolete, as indicated by this text towards the end:
I know. Yet there's
On Fri, 19 Apr 2024 19:29:31 GMT, Alexey Ivanov wrote:
> > We do not have an overall style guide. The conventional wisdom for editing
> > any existing file is to follow the style in that file, if such a style can
> > be discerned.
>
> That's what I do.
>
> I saw either style used in JDK. Yet
On Fri, 19 Apr 2024 10:07:22 GMT, Matthias Baesken wrote:
>> We have already good JLI tracing capabilities. But GetApplicationHome and
>> GetApplicationHomeFromDll lack some tracing and should be enhanced.
>
> Matthias Baesken has updated the pull request incrementally with one
> additional
On Mon, 22 Apr 2024 14:11:41 GMT, Claes Redestad wrote:
>> This switch expression in `Locale::createLocale` is causing a somewhat large
>> startup regression on my local system. Desugaring to if statements seem like
>> the right thing to do while we investigate ways to further reduce overheads
On Fri, 19 Apr 2024 10:07:22 GMT, Matthias Baesken wrote:
>> We have already good JLI tracing capabilities. But GetApplicationHome and
>> GetApplicationHomeFromDll lack some tracing and should be enhanced.
>
> Matthias Baesken has updated the pull request incrementally with one
> additional
On Mon, 22 Apr 2024 14:11:41 GMT, Claes Redestad wrote:
>> This switch expression in `Locale::createLocale` is causing a somewhat large
>> startup regression on my local system. Desugaring to if statements seem like
>> the right thing to do while we investigate ways to further reduce overheads
On Mon, 22 Apr 2024 14:11:41 GMT, Claes Redestad wrote:
>> This switch expression in `Locale::createLocale` is causing a somewhat large
>> startup regression on my local system. Desugaring to if statements seem like
>> the right thing to do while we investigate ways to further reduce overheads
On Mon, 22 Apr 2024 14:11:41 GMT, Claes Redestad wrote:
>> This switch expression in `Locale::createLocale` is causing a somewhat large
>> startup regression on my local system. Desugaring to if statements seem like
>> the right thing to do while we investigate ways to further reduce overheads
> Re-write the IndexOf code without the use of the pcmpestri instruction, only
> using AVX2 instructions. This change accelerates String.IndexOf on average
> 1.3x for AVX2. The benchmark numbers:
>
>
> BenchmarkScore
> Latest
> This switch expression in `Locale::createLocale` is causing a somewhat large
> startup regression on my local system. Desugaring to if statements seem like
> the right thing to do while we investigate ways to further reduce overheads
> in `SwitchBootstraps`.
>
> These numbers are against a
On Fri, 19 Apr 2024 05:18:51 GMT, Laurence Cable wrote:
> I think (I am agreeing with you Severin) that the goal of the heuristic is to
> inform the JVM (and any associated serviceability tools) that the JVM is in a
> resource constrained/managed execution context...
"resource constrained"
On Mon, 22 Apr 2024 13:38:58 GMT, Claes Redestad wrote:
>> src/java.base/share/classes/java/util/Locale.java line 1003:
>>
>>> 1001: return new Locale(lk.base, lk.exts);
>>> 1002: } else {
>>> 1003: throw new InternalError("should not happen");
>>
>> The default
On Mon, 22 Apr 2024 08:46:53 GMT, Per Minborg wrote:
>> While `SymbolLookup` correctly uses an `Optional` return to denote whether a
>> symbol has been found by the lookup or not (which enables composition of
>> symbol lookups), many clients end up just calling `Optional::get`, or
>>
On Mon, 22 Apr 2024 13:05:47 GMT, Chen Liang wrote:
>> This switch expression in `Locale::createLocale` is causing a somewhat large
>> startup regression on my local system. Desugaring to if statements seem like
>> the right thing to do while we investigate ways to further reduce overheads
>>
On Mon, 22 Apr 2024 10:34:29 GMT, Claes Redestad wrote:
> This switch expression in `Locale::createLocale` is causing a somewhat large
> startup regression on my local system. Desugaring to if statements seem like
> the right thing to do while we investigate ways to further reduce overheads
>
> This change drops the adjustments to the virtual thread scheduler's target
> parallelism when virtual threads do file operations on files that are opened
> for buffered I/O. These operations are usually just too short to have any
> benefit and may have a negative benefit when reading/writing
On Wed, 3 Apr 2024 10:04:36 GMT, Alan Bateman wrote:
> This change drops the adjustments to the virtual thread scheduler's target
> parallelism when virtual threads do file operations on files that are opened
> for buffered I/O. These operations are usually just too short to have any
>
On Mon, 22 Apr 2024 10:34:29 GMT, Claes Redestad wrote:
> This switch expression in `Locale::createLocale` is causing a somewhat large
> startup regression on my local system. Desugaring to if statements seem like
> the right thing to do while we investigate ways to further reduce overheads
>
On Mon, 22 Apr 2024 11:30:41 GMT, Matthias Baesken wrote:
> Hi, any additional comments / reviews ? Thanks Matthias
It still looks like left over trace messages from a debugging session, need to
think about about what tracing make sense here.
-
PR Comment:
On Fri, 19 Apr 2024 10:07:22 GMT, Matthias Baesken wrote:
>> We have already good JLI tracing capabilities. But GetApplicationHome and
>> GetApplicationHomeFromDll lack some tracing and should be enhanced.
>
> Matthias Baesken has updated the pull request incrementally with one
> additional
This switch expression in `Locale::createLocale` is causing a somewhat large
startup regression on my local system. Desugaring to if statements seem like
the right thing to do while we investigate ways to further reduce overheads in
`SwitchBootstraps`.
These numbers are against a baseline
On Thu, 18 Apr 2024 14:50:30 GMT, Claes Redestad wrote:
>> This patch suggests a workaround to an issue with huge SCF MH expression
>> trees taking excessive JIT compilation resources by reviving (part of) the
>> simple bytecode-generating strategy that was originally available as an
>>
On Fri, 19 Apr 2024 07:42:19 GMT, Claes Redestad wrote:
>> Investigating a recent regression in mainline I realized we have an
>> opportunity to improve the bootstrap overheads of ObjectMethods::bootstrap
>> by using `invokeExact` in a way similar to what we already do for LMF and
>> SCF
On Thu, 18 Apr 2024 20:11:15 GMT, Claes Redestad wrote:
> Investigating a recent regression in mainline I realized we have an
> opportunity to improve the bootstrap overheads of ObjectMethods::bootstrap by
> using `invokeExact` in a way similar to what we already do for LMF and SCF
> BSMs.
On Fri, 19 Apr 2024 13:23:53 GMT, Claes Redestad wrote:
> We can reduce overhead of first use of a switch bootstrap by moving
> `typePairToName` into `TypePairs` and by explicitly overriding `hashCode` and
> `equals`. The first change avoids loading and initializing the `TypePairs`
> class in
On Sat, 20 Apr 2024 07:39:53 GMT, Chen Liang wrote:
>> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 685:
>>
>>> 683: record TypePairs(Class from, Class to) {
>>> 684:
>>> 685: private static final Map typePairToName =
>>> initialize();
>>
>> IfÂ
> We can reduce overhead of first use of a switch bootstrap by moving
> `typePairToName` into `TypePairs` and by explicitly overriding `hashCode` and
> `equals`. The first change avoids loading and initializing the `TypePairs`
> class in actual cases, the second remove some excess code
> We can reduce overhead of first use of a switch bootstrap by moving
> `typePairToName` into `TypePairs` and by explicitly overriding `hashCode` and
> `equals`. The first change avoids loading and initializing the `TypePairs`
> class in actual cases, the second remove some excess code
> While `SymbolLookup` correctly uses an `Optional` return to denote whether a
> symbol has been found by the lookup or not (which enables composition of
> symbol lookups), many clients end up just calling `Optional::get`, or
> `Optional::orElseThrow()` on the result.
>
> This PR proposes to
41 matches
Mail list logo
