Re: RFR: 8343110: Add getChars(int, int, char[], int) to CharSequence and CharBuffer [v5]

On Tue, 8 Apr 2025 18:12:03 GMT, Chen Liang wrote: > Should we ask hotspot compiler engineers for inputs on how useful this API is > for allowing batch/vectorized copy and eliminating overheads of defensive > copy array allocation? I have no strong feelings about that. As it looks like we rea

Re: RFR: 8305186: Reference.waitForReferenceProcessing should be more accessible to tests [v4]

On Thu, 10 Apr 2025 22:24:04 GMT, Brent Christian wrote: >> Certain specific types of tests involving GC and reference processing need >> to account for the delay between a GC completing (during which the GC clears >> a Reference), and the Reference being added to its associated queue. At >> p

Re: RFR: 8354266: Fix non-UTF-8 text encoding

On Thu, 10 Apr 2025 10:10:49 GMT, Magnus Ihse Bursie wrote: > I have checked the entire code base for incorrect encodings, but luckily > enough these were the only remaining problems I found. > > BOM (byte-order mark) is a method used for distinguishing big and little > endian UTF-16 encoding

Re: RFR: 8305186: Reference.waitForReferenceProcessing should be more accessible to tests [v4]

On Thu, 10 Apr 2025 22:24:04 GMT, Brent Christian wrote: >> Certain specific types of tests involving GC and reference processing need >> to account for the delay between a GC completing (during which the GC clears >> a Reference), and the Reference being added to its associated queue. At >> p

Re: RFR: 8305186: Reference.waitForReferenceProcessing should be more accessible to tests [v3]

On Thu, 10 Apr 2025 22:18:20 GMT, Brent Christian wrote: >> test/lib/jdk/test/whitebox/WhiteBox.java line 570: >> >>> 568:* This method should usually be called after a call to >>> WhiteBox.fullGC(). >>> 569:*/ >>> 570: public static void waitForReferenceProcessing() { >> >> Referenc

Integrated: 8347472: Correct Attribute traversal and writing for Code attributes

On Fri, 7 Feb 2025 19:25:04 GMT, Chen Liang wrote: > Make UnknownAttribute and CustomAttribute delivered in code traversal, and > make sure stack maps update the label references after a code transform when > it is reused. Other code-bound attributes are not updated as they cannot be > supplie

Re: RFR: 8347472: Correct Attribute traversal and writing for Code attributes

On Fri, 7 Feb 2025 19:25:04 GMT, Chen Liang wrote: > Make UnknownAttribute and CustomAttribute delivered in code traversal, and > make sure stack maps update the label references after a code transform when > it is reused. Other code-bound attributes are not updated as they cannot be > supplie

Integrated: 8352748: Remove com.sun.tools.classfile from the JDK

On Tue, 8 Apr 2025 20:34:09 GMT, Chen Liang wrote: > With all dependencies of com.sun.tools.classfile in the JDK converted to the > ClassFile API, we can remove this legacy library for release 25 like how we > removed ASM. > > Testing: built locally, running tier 1-3 tests > > Don't know why,

RE: JDK-8352891 Performance improvements to ByteArrayOutputStream

Thank you, appreciate the guidance! 😊 Will do. John You may of course do as you like, but as a matter of personal preference I usually find it more expedient not to file a CSR until the discussion about what it will contain has become quiescent in the PR itself. Cheers, Brian

Re: RFR: 8354335: No longer deprecate wrapper class constructors for removal

On Thu, 10 Apr 2025 22:05:04 GMT, Roger Riggs wrote: > Remove forRemoval = true from @Deprecated annotation of Boolean, Byte, > Character, Double, Float, Integer, Long, Short. > And add `SuppressWarnings("deprecation") `where needed; and remove > `SuppressWarnings("removal")` The wrapper class

Re: JDK-8352891 Performance improvements to ByteArrayOutputStream

At the risk of repeating my previous comment , I agree with Chen. That is to say, there is a separate, more fundamental unsolved problem lurking underneath this discussion, and the two problem "layers" are perhaps better addr

Re: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v43]

> Implement JEP 502. > > The PR passes tier1-tier3 tests. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Fix doc issue with NULL_SENTINEL - Changes: - all: https://git.openjdk.org/jdk/pull/23972/files - new: https:/

Re: RFR: 8352504: RISC-V: implement and enable CMoveI/L [v5]

> Hi, > Can you help to review this patch? > On riscv, CMoveI/L already were implemented, but there are some gap: > 1. CMoveI/L does not support comparison with float/double, corresponding > tests are not turn on either. > 2. Some optimization of C2 is not turned on, e.g. `Phi -> CMove -> min_max`

Re: RFR: 8348556: Inlining fails earlier for MemorySegment::reinterpret [v6]

On Tue, 8 Apr 2025 11:33:54 GMT, Per Minborg wrote: >> This PR proposes to add some `@ForceInline` annotations in the `Module` >> class in order to assist inlining of FFM var/method handles. >> >> There are also some changes in other classes which, if implemented, can take >> us three addition

Re: RFR: 8344706: Compiler Implementation of Compact Source Files and Instance Main Methods [v2]

On Mon, 7 Apr 2025 18:49:33 GMT, Chen Liang wrote: >> I used "internal objects" because I wanted to avoid naming concrete classes, >> which might or might not be used. Previous drafts mentioned BufferedReader, >> InputStreamReader, and CharsetDecoder. >> >> I could replace "internal objects" w

Re: RFR: 8348556: Inlining fails earlier for MemorySegment::reinterpret [v6]

> This PR proposes to add some `@ForceInline` annotations in the `Module` class > in order to assist inlining of FFM var/method handles. > > There are also some changes in other classes (notably `j.l.Object`) which, if > implemented, can take us four additional levels of inlining. However, there

Re: RFR: 8305186: Reference.waitForReferenceProcessing should be more accessible to tests [v3]

On Thu, 10 Apr 2025 05:33:18 GMT, Kim Barrett wrote: >> Brent Christian has updated the pull request incrementally with one >> additional commit since the last revision: >> >> reflection improvements > > test/lib/jdk/test/whitebox/WhiteBox.java line 572: > >> 570: public static void waitFo

Re: RFR: 8305186: Reference.waitForReferenceProcessing should be more accessible to tests [v3]

On Thu, 10 Apr 2025 06:08:37 GMT, Kim Barrett wrote: >> Brent Christian has updated the pull request incrementally with one >> additional commit since the last revision: >> >> reflection improvements > > test/lib/jdk/test/whitebox/WhiteBox.java line 578: > >> 576: throw new RuntimeExce

Re: RFR: 8353787: Increased number of SHA-384-Digest java.util.jar.Attributes$Name instances leading to higher memory footprint

On Mon, 7 Apr 2025 06:34:11 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which proposes to address the > increase in memory footprint of an application that uses signed JAR files, > signed with `SHA-384` digest algorithm? This addresses > https://bugs.openjdk.org/browse/

Re: RFR: 8305186: Reference.waitForReferenceProcessing should be more accessible to tests [v3]

On Thu, 10 Apr 2025 05:51:04 GMT, Kim Barrett wrote: >> Brent Christian has updated the pull request incrementally with one >> additional commit since the last revision: >> >> reflection improvements > > test/lib/jdk/test/whitebox/WhiteBox.java line 570: > >> 568:* This method should usu

Re: RFR: 8305186: Reference.waitForReferenceProcessing should be more accessible to tests [v4]

> Certain specific types of tests involving GC and reference processing need to > account for the delay between a GC completing (during which the GC clears a > Reference), and the Reference being added to its associated queue. At > present, ad hoc mechanisms (with delays/timeout) are used, but c

RFR: 8354335: No longer deprecate wrapper class constructors for removal

Remove forRemoval = true from @Deprecated annotation of Boolean, Byte, Character, Double, Float, Integer, Long, Short. And add `SuppressWarnings("deprecation") `where needed; and remove `SuppressWarnings("removal")` - Commit messages: - 8354335: No longer deprecate wrapper class co

Re: RFR: 8354320: Changes to jpackage.md cause pandoc warning

On Thu, 10 Apr 2025 21:50:10 GMT, Alexey Semenyuk wrote: > Escape the dollar sign. @sashamatveev PTAL @magicus PTAL - PR Comment: https://git.openjdk.org/jdk/pull/24585#issuecomment-2795242824 PR Comment: https://git.openjdk.org/jdk/pull/24585#issuecomment-2795249016

RFR: 8354320: Changes to jpackage.md cause pandoc warning

Escape the dollar sign. - Commit messages: - 8354320: Changes to jpackage.md cause pandoc warning Changes: https://git.openjdk.org/jdk/pull/24585/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24585&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8354320 Stats: 1 l

Re: RFR: 8341641: Make %APPDATA% and %LOCALAPPDATA% env variables available in *.cfg files [v10]

On Thu, 10 Apr 2025 16:52:15 GMT, Alexey Semenyuk wrote: >> I'm guessing a possible fix would be to use >> >> `${` >> >> or >> >> "`${`" >> >> instead. >> >> Alternatively, we need to tell pandoc to not try and use any encoded TeX >> math in markdown files. > > I filed https://bugs.openjdk

Re: RFR: 8353786: Migrate Vector API math library support to FFM API [v4]

On Mon, 7 Apr 2025 23:20:05 GMT, Vladimir Ivanov wrote: >> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/CPUFeatures.java >> line 60: >> >>> 58: } >>> 59: >>> 60: public static class X64 { >> >> Should we create `src/jdk.incubator.vector/cpu/` for CPU specific >> inform

Integrated: 8351740: Clean up some code around initialization of encoding properties

On Fri, 4 Apr 2025 23:42:26 GMT, Stuart Marks wrote: > Some of the code that creates various encoding properties at JVM > initialization time, such as file.encoding and native.encoding, could use > some cleaning up. Cleanup is fairly minimal and should be mostly > behavior-preserving. Changes

Re: RFR: 8348978: Regression ~8% on J2dBench-vimg_text_aa-ParGC only on linux aarch64 [v2]

> This PR proposes to use an anonymous class rather than a lambda in order to > improve startup time. > > We need to make sure the regression is fixed by this. It might be the case > that the regression is there because > [JDK-8347047](https://bugs.openjdk.org/browse/JDK-8347047) actually fixed

Re: RFR: 8353786: Migrate Vector API math library support to FFM API [v4]

On Mon, 7 Apr 2025 23:32:05 GMT, Vladimir Ivanov wrote: >> Migrate Vector API math library (SVML and SLEEF) linkage from native code >> (in JVM) to Java FFM API. >> >> Since FFM API doesn't support vector calling conventions yet, migration >> affects only symbol lookup for now. But it still en

Re: RFR: 8354266: Fix non-UTF-8 text encoding

On Thu, 10 Apr 2025 18:30:22 GMT, Eirik Bjørsnøs wrote: >> If this is a French name, it's e acute: é. > >> If this is a French name, it's e acute: é. > > Supported by this Wikipedia page listing S.L as an LCMS developer: > > https://en.wikipedia.org/wiki/Little_CMS It's not a mistake in capita

Re: RFR: 8354111: JavaDoc states that Iterator.remove() is linear in the LinkedBlockingDeque

On Wed, 9 Apr 2025 12:36:21 GMT, Chen Liang wrote: >> One of the features of the LinkedBlockingDeque is that it is a doubly-linked >> node queue, with pointers in each node to "prev" and "next", which allows >> remove() in the Iterator to remove the node in constant time. However, in >> the Ja

Re: RFR: 8348986: Improve coverage of enhanced exception messages [v5]

On Thu, 10 Apr 2025 21:26:21 GMT, Michael McMahon wrote: >> Hi, >> >> Enhanced exception messages are designed to hide sensitive information such >> as hostnames, IP >> addresses from exception message strings, unless the enhanced mode for the >> specific category >> has been explicitly enab

Re: RFR: 8354266: Fix non-UTF-8 text encoding

On Thu, 10 Apr 2025 10:10:49 GMT, Magnus Ihse Bursie wrote: > I have checked the entire code base for incorrect encodings, but luckily > enough these were the only remaining problems I found. > > BOM (byte-order mark) is a method used for distinguishing big and little > endian UTF-16 encoding

Re: RFR: 8354266: Fix non-UTF-8 text encoding

On Thu, 10 Apr 2025 19:06:35 GMT, Eirik Bjørsnøs wrote: > (BTW, I enjoyed seeing separate commits for the encoding and BOM changes, > makes it easier to verify each!) Thanks! I do very much like myself to review PRs that has separate logical commits, so I try to produce such myself. I'm glad t

Re: RFR: 8348986: Improve coverage of enhanced exception messages [v5]

> Hi, > > Enhanced exception messages are designed to hide sensitive information such > as hostnames, IP > addresses from exception message strings, unless the enhanced mode for the > specific category > has been explicitly enabled. Enhanced exceptions were first introduced in > 8204233 in JD

Re: RFR: 8341641: Make %APPDATA% and %LOCALAPPDATA% env variables available in *.cfg files [v9]

> jpackage app laucnher will expand environment variables in .cfg files. > > Previously jpackage app launcher only replaced `$APPDIR`, `$BINDIR`, and > `$ROOTDIR` tokens with the corresponding path values. With this patch, any > environment variable can be expanded. The syntax is shell-like > `

Re: RFR: 8353185: Introduce the concept of upgradeable files in context of JEP 493 [v4]

On Mon, 7 Apr 2025 13:35:57 GMT, Severin Gehwolf wrote: >> For JEP 493-enabled builds there are no JMODs. Certain files come from the >> installed JDK image when a user creates a custom run-time from it. This is >> problematic for example for files that often come from a different package >> (

Re: RFR: 8342382: Implementation of JEP G1: Improve Application Throughput with a More Efficient Write-Barrier [v30]

On Wed, 9 Apr 2025 14:32:43 GMT, Thomas Schatzl wrote: >> src/hotspot/share/gc/g1/g1ConcurrentRefineSweepTask.cpp line 83: >> >>> 81: break; >>> 82: } >>> 83: case G1RemSet::HasRefToOld : break; // Nothing special to do. >> >> Why doesn't call `inc_cards_clean_again` in this

Re: RFR: 8344706: Compiler Implementation of Compact Source Files and Instance Main Methods

On Sat, 5 Apr 2025 02:31:21 GMT, Chen Liang wrote: >> src/java.base/share/classes/java/lang/IO.java line 122: >> >>> 120: public static void print(Object obj) { >>> 121: System.out.print(obj); >>> 122: System.out.flush(); >> >> Is it worth using a local variable to avoid cal

Re: RFR: 8353641: Deprecate core library permission classes for removal [v8]

> Now that the Security Manager is permanently disabled, the following > permission classes in the core libraries area can be deprecated for removal > as they are no longer useful: FilePermission, LinkPermission, > LoggingPermission, PropertyPermission, ReflectPermission, RuntimePermission, > a

Re: RFR: 8353786: Migrate Vector API math library support to FFM API [v3]

On Mon, 7 Apr 2025 06:44:16 GMT, Per Minborg wrote: >> Vladimir Ivanov has updated the pull request incrementally with one >> additional commit since the last revision: >> >> features_string -> cpu_info_string > > src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMathLibrary.j

Re: RFR: 8353786: Migrate Vector API math library support to FFM API [v3]

On Mon, 7 Apr 2025 17:01:19 GMT, Vladimir Kozlov wrote: >> Vladimir Ivanov has updated the pull request incrementally with one >> additional commit since the last revision: >> >> features_string -> cpu_info_string > > src/jdk.incubator.vector/share/classes/jdk/incubator/vector/CPUFeatures.jav

Re: RFR: 8344706: Compiler Implementation of Compact Source Files and Instance Main Methods [v4]

> This is a PR that implements JEP: Compact Source Files and Instance Main > Methods. Changes include: > - `java.io.IO` moved to `java.lang.IO`, and no longer uses `System.console()` > to implement the methods (thanks to @stuart-marks) > - `java. ... .IO` is no longer automatically imported in an

Re: RFR: 8352730: RISC-V: Disable tests in qemu-user [v3]

On Thu, 10 Apr 2025 02:13:46 GMT, Fei Yang wrote: > > qemu-user, "uarch: qemu" in cpuinfo: `[0.084s][info ][os,cpu] CPU: total 28 > > (initial active 28) qemu rv64 rvi rvm rva rvf rvd rvc rvv zba zbb zbs zfh > > zfhmin zvbc zvfh zicond` Hence we know this is qemu-user (only qemu-user > > sets

Re: RFR: 8350075: Performance difference between SegmentAllocator methods

On Fri, 14 Feb 2025 09:19:35 GMT, Per Minborg wrote: > This PR proposes to add `@ForceInline` to the `default` methods in > `SegmentAllocator` that do not already have it. Base: Benchmark Mode Cnt Score Error Units AllocFromInlineTest.alloc00 thrpt

Re: RFR: 8351740: Clean up some code around initialization of encoding properties [v3]

On Thu, 10 Apr 2025 18:14:52 GMT, Stuart Marks wrote: >> Some of the code that creates various encoding properties at JVM >> initialization time, such as file.encoding and native.encoding, could use >> some cleaning up. Cleanup is fairly minimal and should be mostly >> behavior-preserving. Cha

Re: RFR: 8351740: Clean up some code around initialization of encoding properties [v3]

On Thu, 10 Apr 2025 18:14:52 GMT, Stuart Marks wrote: >> Some of the code that creates various encoding properties at JVM >> initialization time, such as file.encoding and native.encoding, could use >> some cleaning up. Cleanup is fairly minimal and should be mostly >> behavior-preserving. Cha

Re: RFR: 8344706: Compiler Implementation of Compact Source Files and Instance Main Methods [v2]

On Mon, 7 Apr 2025 09:12:27 GMT, Alan Bateman wrote: >> Jan Lahoda has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Use local variable for System.out in print(). > > src/java.base/share/classes/java/lang/IO.java line 45: > >> 43: * UTF-

Re: JDK-8352891 Performance improvements to ByteArrayOutputStream

On 08/04/2025 13:51, Engebretson, John wrote:   Brian, Alan, Markus, Chen – thank you for your feedback on this issue!  At this point we seem to agree that 1) there is merit to this idea, 2) nobody loves a new public class (including me), and 3) this is not a subclass of ByteArrayOutputStream

Re: RFR: 8353185: Introduce the concept of upgradeable files in context of JEP 493 [v3]

On Mon, 7 Apr 2025 12:21:06 GMT, Severin Gehwolf wrote: >> test/jdk/tools/jlink/runtimeImage/UpgradeableFileCacertsTest.java line 42: >> >>> 40: /* >>> 41: * @test >>> 42: * @summary Verify that no errors are reported for files the have been >> >> Suggestion: >> >> * @summary Verify that no

Re: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v46]

> Implement JEP 502. > > The PR passes tier1-tier3 tests. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Fix typo - Changes: - all: https://git.openjdk.org/jdk/pull/23972/files - new: https://git.openjdk.org/jdk/pul

Integrated: 8353641: Deprecate core library permission classes for removal

On Fri, 4 Apr 2025 12:37:32 GMT, Roger Riggs wrote: > Now that the Security Manager is permanently disabled, the following > permission classes in the core libraries area can be deprecated for removal > as they are no longer useful: FilePermission, LinkPermission, > LoggingPermission, Property

Re: RFR: 8353840: JNativeScan should not throw error for missing system classes

On Tue, 8 Apr 2025 12:00:41 GMT, Danish Nawab wrote: >>> This catch block is per-method. It means that if the rest of the method >>> contained references to restricted methods, we would not see them. The >>> catch block should be moved to be just around the call to isRestricted, >>> which can

Re: RFR: 8352748: Remove com.sun.tools.classfile from the JDK [v2]

> With all dependencies of com.sun.tools.classfile in the JDK converted to the > ClassFile API, we can remove this legacy library for release 25 like how we > removed ASM. > > Testing: built locally, running tier 1-3 tests > > Don't know why, but GitHub is redundantly displaying changes that ar

Re: RFR: 8354266: Fix non-UTF-8 text encoding

On Thu, 10 Apr 2025 10:10:49 GMT, Magnus Ihse Bursie wrote: > I have checked the entire code base for incorrect encodings, but luckily > enough these were the only remaining problems I found. > > BOM (byte-order mark) is a method used for distinguishing big and little > endian UTF-16 encoding

Re: RFR: 8353786: Migrate Vector API math library support to FFM API

On Fri, 4 Apr 2025 22:52:24 GMT, Vladimir Ivanov wrote: > Migrate Vector API math library (SVML and SLEEF) linkage from native code (in > JVM) to Java FFM API. > > Since FFM API doesn't support vector calling conventions yet, migration > affects only symbol lookup for now. But it still enables

Re: RFR: 8354111: JavaDoc states that Iterator.remove() is linear in the LinkedBlockingDeque

On Tue, 8 Apr 2025 08:50:37 GMT, kabutz wrote: > One of the features of the LinkedBlockingDeque is that it is a doubly-linked > node queue, with pointers in each node to "prev" and "next", which allows > remove() in the Iterator to remove the node in constant time. However, in the > JavaDoc of

Re: RFR: 8352642: Set zipinfo-time=false when constructing zipfs FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for better performance [v2]

On Tue, 8 Apr 2025 09:21:50 GMT, Jaikiran Pai wrote: >> Jason Zaugg has updated the pull request incrementally with one additional >> commit since the last revision: >> >> 8352642: Also pass zipinfo-time to the alternative newFileSystem call > > src/jdk.compiler/share/classes/com/sun/tools/ja

Re: java.lang.String hashCode and @Stable ?

Hi Chen, I think we can choose an arbitrary non-zero number and assign it to the `hash` field when the calculated hash is 0. This has two costs: 1. When the hash is 0, both the hash and hashIsZero fields need to be written after the hash is calculated; 2. When the hash is really just th

Re: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native [v2]

On Thu, 10 Apr 2025 08:44:28 GMT, Eirik Bjørsnøs wrote: >> Justin Lu has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Replace InputStreamReader with BufferedReader > > FWIW, I checked out the revision of the commit previous to this change

Re: RFR: 8354266: Fix non-UTF-8 text encoding

On Thu, 10 Apr 2025 10:10:49 GMT, Magnus Ihse Bursie wrote: > I have checked the entire code base for incorrect encodings, but luckily > enough these were the only remaining problems I found. > > BOM (byte-order mark) is a method used for distinguishing big and little > endian UTF-16 encoding

Re: RFR: 8354266: Fix non-UTF-8 text encoding

On Thu, 10 Apr 2025 17:23:37 GMT, Raffaello Giulietti wrote: > If this is a French name, it's e acute: é. Supported by this Wikipedia page listing S.L as an LCMS developer: https://en.wikipedia.org/wiki/Little_CMS - PR Review Comment: https://git.openjdk.org/jdk/pull/24566#discus

Re: RFR: 8344708: Compiler Implementation of Module Import Declarations [v5]

On Thu, 10 Apr 2025 18:04:54 GMT, Jan Lahoda wrote: >> This is a patch to finalize the module imports feature. Please see: >> https://bugs.openjdk.org/browse/JDK-8344700 > > Jan Lahoda has updated the pull request incrementally with one additional > commit since the last revision: > > Reflect

Re: RFR: 8332249: Micro-optimize Method.hashCode [v2]

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 >

Re: RFR: 8352565: Add native method implementation of Reference.get() [v4]

On Thu, 10 Apr 2025 08:08:32 GMT, Aleksey Shipilev wrote: >> Kim Barrett has updated the pull request incrementally with three additional >> commits since the last revision: >> >> - remove timeout by using waitForReferenceProcessing >> - make ill-timed gc in non-concurrent case less likely >>

Re: java.lang.String hashCode and @Stable ?

Hi Remi, I think this is probably due to these fields being added too early - the stable on string byte array is also added lately. That said, I don't think adding stable on both fields completely resolves the constant folding issues around string hash code. The current code can only constant f

Re: RFR: 8351740: Clean up some code around initialization of encoding properties [v2]

On Thu, 10 Apr 2025 18:11:06 GMT, Stuart Marks wrote: >> src/java.base/share/classes/jdk/internal/util/SystemProps.java line 79: >> >>> 77: // Platform defined encodings cannot be overridden on the >>> command line >>> 78: put(props, "sun.jnu.encoding", >>> raw.propDefault(Raw.

Re: RFR: 8351740: Clean up some code around initialization of encoding properties [v2]

On Thu, 10 Apr 2025 08:31:40 GMT, Alan Bateman wrote: >> Stuart Marks has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Fix comment from file.encoding to native.encoding > > src/java.base/share/classes/jdk/internal/util/SystemProps.java li

Re: RFR: 8351740: Clean up some code around initialization of encoding properties [v3]

> Some of the code that creates various encoding properties at JVM > initialization time, such as file.encoding and native.encoding, could use > some cleaning up. Cleanup is fairly minimal and should be mostly > behavior-preserving. Changes include the following: > > * In the java_props.h and j

Re: RFR: 8344708: Compiler Implementation of Module Import Declarations [v4]

On Wed, 9 Apr 2025 17:52:26 GMT, Alan Bateman wrote: >> Jan Lahoda has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Reflecting review feedback - avoiding hardcoded constants. > > src/java.base/share/classes/jdk/internal/module/ModuleInfo.

Re: RFR: 8344708: Compiler Implementation of Module Import Declarations [v5]

> This is a patch to finalize the module imports feature. Please see: > https://bugs.openjdk.org/browse/JDK-8344700 Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Reflecting review feedback: cleanup formatting in ModuleInfo. -

Re: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns, instanceof, and switch (Preview) [v57]

On Sun, 6 Apr 2025 10:50:50 GMT, Luca Kellermann wrote: >> Aggelos Biboudis has updated the pull request with a new target base due to >> a merge or a rebase. The pull request now contains 78 commits: >> >> - Merge branch 'master' into primitive-patterns >> - Update summary in ExactnessConver

Re: RFR: 8344706: Compiler Implementation of Compact Source Files and Instance Main Methods [v2]

On Mon, 7 Apr 2025 18:08:29 GMT, Stuart Marks wrote: >> src/java.base/share/classes/java/lang/IO.java line 45: >> >>> 43: * UTF-8 is used instead. These internal objects are created upon the >>> first call to >>> 44: * either of the {@code readln} methods and are stored for subsequent >>> re

Re: RFR: 8351757: Test java/foreign/TestDeadlock.java#FileChannel_map timed out after passing

On Tue, 8 Apr 2025 13:59:11 GMT, Per Minborg wrote: > This PR proposes to increase the timeout values for two tests. Thanks for the reviews! - PR Comment: https://git.openjdk.org/jdk/pull/24511#issuecomment-2789578764

Re: RFR: 8315130: java.lang.IllegalAccessError when processing classlist to create CDS archive [v4]

On Mon, 7 Apr 2025 16:15:47 GMT, Ioi Lam wrote: >> Timofei Pushkin has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Don't use URLClassPath > > src/java.base/share/classes/jdk/internal/misc/CDS.java line 444: > >> 442: protected C

RFR: 8354266: Fix non-UTF-8 text encoding

I have checked the entire code base for incorrect encodings, but luckily enough these were the only remaining problems I found. BOM (byte-order mark) is a method used for distinguishing big and little endian UTF-16 encodings. There is a special UTF-8 BOM, but it is discouraged. In the words of

Re: RFR: 8315130: java.lang.IllegalAccessError when processing classlist to create CDS archive [v4]

On Tue, 8 Apr 2025 11:46:27 GMT, Timofei Pushkin wrote: >> src/java.base/share/classes/jdk/internal/misc/CDS.java line 444: >> >>> 442: protected Class findClass(String name) throws >>> ClassNotFoundException { >>> 443: // Unregistered classes should be found in load(...),

RFR: 8354111: JavaDoc states that Iterator.remove() is linear in the LinkedBlockingDeque

One of the features of the LinkedBlockingDeque is that it is a doubly-linked node queue, with pointers in each node to "prev" and "next", which allows remove() in the Iterator to remove the node in constant time. However, in the JavaDoc of the class, it lists Iterator.remove() as an example of a

Re: RFR: 8341402: BigDecimal's square root optimization [v31]

On Tue, 18 Mar 2025 14:46:01 GMT, fabioromano1 wrote: >> fabioromano1 has updated the pull request incrementally with one additional >> commit since the last revision: >> >> An optimization > > This comment is to avoid closing this PR. > @fabioromano1 Thanks so much for your great work and p

Re: RFR: 8353185: Introduce the concept of upgradeable files in context of JEP 493 [v5]

> For JEP 493-enabled builds there are no JMODs. Certain files come from the > installed JDK image when a user creates a custom run-time from it. This is > problematic for example for files that often come from a different package > (e.g. `cacerts` file for Linux distro builds of OpenJDK package

Re: RFR: 8351462: Improve robustness of String concatenation [v2]

On Wed, 9 Apr 2025 13:32:00 GMT, Raffaello Giulietti wrote: >> Early detection of an `int` overflow in `StringConcatHelper` improves >> robustness of `StringConcatFactory`. > > Raffaello Giulietti has updated the pull request incrementally with one > additional commit since the last revision:

Re: RFR: 8353787: Increased number of SHA-384-Digest java.util.jar.Attributes$Name instances leading to higher memory footprint

On Mon, 7 Apr 2025 06:34:11 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which proposes to address the > increase in memory footprint of an application that uses signed JAR files, > signed with `SHA-384` digest algorithm? This addresses > https://bugs.openjdk.org/browse/

Re: RFR: 8354266: Fix non-UTF-8 text encoding

On Thu, 10 Apr 2025 10:10:49 GMT, Magnus Ihse Bursie wrote: > I have checked the entire code base for incorrect encodings, but luckily > enough these were the only remaining problems I found. > > BOM (byte-order mark) is a method used for distinguishing big and little > endian UTF-16 encoding

Re: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v53]

On Thu, 10 Apr 2025 10:26:36 GMT, Per Minborg wrote: >> Implement JEP 502. >> >> The PR passes tier1-tier3 tests. > > Per Minborg has updated the pull request incrementally with one additional > commit since the last revision: > > Improve docs as per comments > > ``` > > > > I will take a

Re: RFR: 8354266: Fix non-UTF-8 text encoding

On Thu, 10 Apr 2025 10:10:49 GMT, Magnus Ihse Bursie wrote: > I have checked the entire code base for incorrect encodings, but luckily > enough these were the only remaining problems I found. > > BOM (byte-order mark) is a method used for distinguishing big and little > endian UTF-16 encoding

Re: RFR: 8350462: MethodTypeForm.LF_INTERPRET can cache the MemberName instead [v2]

On Sun, 6 Apr 2025 08:09:27 GMT, Zihao Lin wrote: >> Modify the cache in MethodTypeForm that currently stores the LF_INTERPRET >> Lambda form. Instead of caching the entire LambdaForm, change it to store a >> SoftReference. This will avoid unnecessary memory usage. > > Zihao Lin has updated the

Integrated: 8350462: MethodTypeForm.LF_INTERPRET can cache the MemberName instead

On Sat, 5 Apr 2025 14:26:13 GMT, Zihao Lin wrote: > Modify the cache in MethodTypeForm that currently stores the LF_INTERPRET > Lambda form. Instead of caching the entire LambdaForm, change it to store a > SoftReference. This will avoid unnecessary memory usage. This pull request has now been

Re: RFR: 8354266: Fix non-UTF-8 text encoding

On Thu, 10 Apr 2025 17:09:27 GMT, Naoto Sato wrote: >> I have checked the entire code base for incorrect encodings, but luckily >> enough these were the only remaining problems I found. >> >> BOM (byte-order mark) is a method used for distinguishing big and little >> endian UTF-16 encodings.

Re: RFR: 8350462: MethodTypeForm.LF_INTERPRET can cache the MemberName instead [v2]

On Sun, 6 Apr 2025 08:09:27 GMT, Zihao Lin wrote: >> Modify the cache in MethodTypeForm that currently stores the LF_INTERPRET >> Lambda form. Instead of caching the entire LambdaForm, change it to store a >> SoftReference. This will avoid unnecessary memory usage. > > Zihao Lin has updated the

Re: RFR: 8353917: jnativescan: Simplify ClassResolver [v2]

On Wed, 9 Apr 2025 16:00:52 GMT, Jorn Vernee wrote: >> `jnativescan` uses the `ClassResolver` class to find both system classes, as >> well as application classes. In principle, a class resolver supports both >> iterating over all classes from that particular source, as well as looking >> up c

Re: RFR: 8348556: Inlining fails earlier for MemorySegment::reinterpret [v7]

On Tue, 8 Apr 2025 12:24:41 GMT, Per Minborg wrote: >> This PR proposes to add some `@ForceInline` annotations in the `Module` >> class in order to assist inlining of FFM var/method handles. >> >> There are also some changes in other classes which, if implemented, can take >> us three addition

Re: RFR: 8354266: Fix non-UTF-8 text encoding

On Thu, 10 Apr 2025 10:10:49 GMT, Magnus Ihse Bursie wrote: > I have checked the entire code base for incorrect encodings, but luckily > enough these were the only remaining problems I found. > > BOM (byte-order mark) is a method used for distinguishing big and little > endian UTF-16 encoding

Re: RFR: 8353917: jnativescan: Simplify ClassResolver [v2]

On Thu, 10 Apr 2025 14:48:59 GMT, Maurizio Cimadamore wrote: >> Jorn Vernee has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains four commits: >> >> - Merge branch 'master' into jnativescan_Refactor >> - bump copyright years >> - m

Re: RFR: 8353917: jnativescan: Simplify ClassResolver [v3]

> `jnativescan` uses the `ClassResolver` class to find both system classes, as > well as application classes. In principle, a class resolver supports both > iterating over all classes from that particular source, as well as looking up > classes by name. However, the `ClassResolver` for system cl

Re: RFR: 8341641: Make %APPDATA% and %LOCALAPPDATA% env variables available in *.cfg files [v10]

On Thu, 10 Apr 2025 14:44:06 GMT, Magnus Ihse Bursie wrote: >> src/jdk.jpackage/share/man/jpackage.md line 228: >> >>> 226: An expandable substring should be enclosed between the dollar >>> 227: sign character ($) and the first following non-alphanumeric >>> 228: character. Alternati

Re: RFR: 8354266: Fix non-UTF-8 text encoding

On Thu, 10 Apr 2025 11:46:45 GMT, Raffaello Giulietti wrote: > I guess the difference at L.1 in the various files is just the BOM? Yes. - PR Review Comment: https://git.openjdk.org/jdk/pull/24566#discussion_r2037357899

Re: RFR: 8342382: Implementation of JEP G1: Improve Application Throughput with a More Efficient Write-Barrier [v30]

On Thu, 10 Apr 2025 10:58:24 GMT, Thomas Schatzl wrote: >> I remember significant impact in some microbenchmark. It's also inlined in >> Parallel GC. I do not consider it a big issue wrt to maintenance - these >> things never really change, and the method is small and contained. >> I will try t

RFR: 8305186: Reference.waitForReferenceProcessing should be more accessible to tests

Certain specific types of tests involving GC and reference processing need to account for the delay between a GC completing (during which the GC clears a Reference), and the Reference being added to its associated queue. At present, ad hoc mechanisms (with delays/timeout) are used, but can lead

Re: RFR: 8342382: Implementation of JEP G1: Improve Application Throughput with a More Efficient Write-Barrier [v31]

> Hi all, > > please review this change that implements (currently Draft) JEP: G1: > Improve Application Throughput with a More Efficient Write-Barrier. > > The reason for posting this early is that this is a large change, and the JEP > process is already taking very long with no end in sight

RFR: 8354273: Restore even more pointless unicode characters to ASCII

As a follow-up to [JDK-8354213](https://bugs.openjdk.org/browse/JDK-8354213), I found some additional places where unicode characters are unnecessarily used instead of pure ASCII. - Commit messages: - 8354273: Restore even more pointless unicode characters to ASCII Changes: https:

  1   2   >