Re: RFR: 8327499: MethodHandleStatics.traceLambdaForm includes methods that cannot be generated [v2]

> GenerateJLIClassesHelper has been making wrong assumptions about Invoker's > LambdaForm method type parameters. Since they are distinct from those of > Linkers, they are now tracked and generated separately. It seems that no > proper invoker was ever generated before, except it happens that mo

Re: RFR: 8327499: MethodHandleStatics.traceLambdaForm includes methods that cannot be generated

On Fri, 10 May 2024 04:23:35 GMT, Ioi Lam wrote: >> GenerateJLIClassesHelper has been making wrong assumptions about Invoker's >> LambdaForm method type parameters. Since they are distinct from those of >> Linkers, they are now tracked and generated separately. It seems that no >> proper invok

Re: RFR: 8305457: Implement java.io.IO [v7]

On Thu, 9 May 2024 18:27:08 GMT, Pavel Rappo wrote: >> Please review this PR which introduces the `java.io.IO` top-level class and >> three methods to `java.io.Console` for [Implicitly Declared Classes and >> Instance Main Methods (Third Preview)]. >> >> This PR has been obtained as `git merge

Re: RFR: 8327499: MethodHandleStatics.traceLambdaForm includes methods that cannot be generated

On Fri, 10 May 2024 00:45:31 GMT, Chen Liang wrote: > GenerateJLIClassesHelper has been making wrong assumptions about Invoker's > LambdaForm method type parameters. Since they are distinct from those of > Linkers, they are now tracked and generated separately. It seems that no > proper invoke

Re: RFR: 8331879: Clean up non-standard use of /// comments in `java.base`

On Thu, 9 May 2024 02:09:50 GMT, xiaotaonan wrote: > Clean up non-standard use of /// comments in `java.base` @mdinacci @hns @landonf - PR Comment: https://git.openjdk.org/jdk/pull/19151#issuecomment-2103685769

Re: RFR: 8328821: Map.of().entrySet() mutators should throw UnsupportedOperationException

On Wed, 27 Mar 2024 17:36:28 GMT, Liam Miller-Cushon wrote: > This change overrides mutator methods in the implementation returned by > `Map.of().entrySet()` to throw `UnsupportedOperationException`. @stuart-marks Can you take a look at this? - PR Comment: https://git.openjdk.org/

Re: RFR: 8330988: Implementation of 8288293: Windows/gcc Port for hsdis

On Wed, 24 Apr 2024 09:15:21 GMT, Magnus Ihse Bursie wrote: >> WIP >> >> This changeset contains hsdis for Windows/gcc Port. It supports both the >> binutils and capstone backends, though the LLVM backend is left out due to >> compatibility issues encountered during the build. Currently, which

Re: RFR: 8331907: BigInteger and BigDecimal should use optimized division

On Wed, 8 May 2024 08:19:54 GMT, Daniel Jeliński wrote: > Replace the custom unsigned divide / remainder functions with the > compiler-optimized Long.divideUnsigned / remainderUnsigned. > > No new tests. Existing tier1-3 tests continue to pass. > > I added a new set of divide benchmarks. Resul

Re: Status of ZIP64 InputStream bug JDK-8298530?

I think this might have been addressed in mainline through https://bugs.openjdk.org/browse/JDK-8303866 -Jaikiran On 09/05/24 11:39 pm, Archie Cobbs wrote: On Thu, May 9, 2024 at 12:43 PM Bernd Eckenfels wrote: But this one here is still open: * [JDK-8298530] ZipInputStream.readEnd

RFR: 8327499: MethodHandleStatics.traceLambdaForm includes methods that cannot be generated

GenerateJLIClassesHelper has been making wrong assumptions about Invoker's LambdaForm method type parameters. Since they are distinct from those of Linkers, they are now tracked and generated separately. It seems that no proper invoker was ever generated before, except it happens that most invok

Withdrawn: 8325576: java/lang/ProcessHandle/InfoTest.java fails on systems with coreutils with --enable-single-binary

On Fri, 9 Feb 2024 23:40:00 GMT, Dan Lutker wrote: > Ran the test on AmazonLinux 2 which has multiple binaries from coreutils > package and no coreutils executable as well as AmazonLinux 2023 that uses > `--enable-single-binary` This pull request has been closed without being integrated.

Re: RFR: 8331876: JFR: Move file read and write events to java.base [v3]

On Thu, 9 May 2024 14:59:34 GMT, Erik Gahlin wrote: >> src/java.base/share/classes/java/io/FileInputStream.java line 63: >> >>> 61: private static final int DEFAULT_BUFFER_SIZE = 8192; >>> 62: >>> 63: // Flag that determines if file reads should be traced by JFR >> >> It could be good

Re: RFR: 8330182: Start of release updates for JDK 24 [v4]

> Get JDK 24 underway. Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: - Adjust test for deprecated options. - Merge branch 'master' into JDK-8330188 - Update deprecated options test. - Merge branch 'master'

Re: RFR: 8329538: Accelerate P256 on x86_64 using Montgomery intrinsic [v9]

> Performance. Before: > > Benchmark(algorithm) (dataSize) (keyLength) > (provider) Mode Cnt ScoreError Units > SignatureBench.ECDSA.signSHA256withECDSA1024 256 > thrpt3 6443.934 ± 6.491 ops/s > SignatureBench.ECDSA.

Re: RFR: 8329538: Accelerate P256 on x86_64 using Montgomery intrinsic [v7]

On Thu, 9 May 2024 23:36:03 GMT, Anthony Scarpino wrote: >> Volodymyr Paprotski has updated the pull request incrementally with one >> additional commit since the last revision: >> >> whitespace > > src/java.base/share/classes/sun/security/ec/ECOperations.java line 701: > >> 699:

Re: RFR: 8329538: Accelerate P256 on x86_64 using Montgomery intrinsic [v8]

> Performance. Before: > > Benchmark(algorithm) (dataSize) (keyLength) > (provider) Mode Cnt ScoreError Units > SignatureBench.ECDSA.signSHA256withECDSA1024 256 > thrpt3 6443.934 ± 6.491 ops/s > SignatureBench.ECDSA.

Re: RFR: 8329538: Accelerate P256 on x86_64 using Montgomery intrinsic [v7]

On Thu, 9 May 2024 22:23:02 GMT, Volodymyr Paprotski wrote: >> Performance. Before: >> >> Benchmark(algorithm) (dataSize) (keyLength) >> (provider) Mode Cnt ScoreError Units >> SignatureBench.ECDSA.signSHA256withECDSA1024 256 >

Re: RFR: 8331646: Add specific regression leap year tests [v4]

On Thu, 9 May 2024 09:10:20 GMT, serhiysachkov wrote: >> Calendar.add() tests that describe its behavior. > > serhiysachkov has updated the pull request incrementally with one additional > commit since the last revision: > > JDK-8331646 updating impl according to review requests LGTM. Please

Re: RFR: 8329538: Accelerate P256 on x86_64 using Montgomery intrinsic [v7]

> Performance. Before: > > Benchmark(algorithm) (dataSize) (keyLength) > (provider) Mode Cnt ScoreError Units > SignatureBench.ECDSA.signSHA256withECDSA1024 256 > thrpt3 6443.934 ± 6.491 ops/s > SignatureBench.ECDSA.

Re: RFR: 8331744: java.lang.classfile.TypeKind improvements [v5]

On Thu, 9 May 2024 21:15:31 GMT, Chen Liang wrote: >> A peek into TypeKind during the research for #19105 reveals that TypeKind >> has a few issues: >> 1. Name mismatch for `newarraycode` and `fromNewArrayCode`: Renamed both to >> use "newarray code" >> 2. `fromDescriptor` can throw IOOBE if th

Re: RFR: 8331744: java.lang.classfile.TypeKind improvements [v5]

> A peek into TypeKind during the research for #19105 reveals that TypeKind has > a few issues: > 1. Name mismatch for `newarraycode` and `fromNewArrayCode`: Renamed both to > use "newarray code" > 2. `fromDescriptor` can throw IOOBE if the input string is empty: changed to > throw IAE and added

Re: RFR: 8311175: Move BufWriter::asByteBuffer to BufWriterImpl [v3]

> As discussed on the mailing list > https://mail.openjdk.org/pipermail/classfile-api-dev/2023-June/000381.html, > BufWriter::asByteBuffer has a behavior not suitable for API and is only used > by internal StackMapGenerator/StackCounter, so it will be converted to an > internal API. > > Someho

Re: RFR: 8329581: Java launcher no longer prints a stack trace [v9]

On Wed, 8 May 2024 09:37:58 GMT, Thomas Stuefe wrote: > This may be food for another RFE, to keep this patch minimal. But a good > solution, to me, would be like this: > > * have the same logic for return codes (1 = error, 0 = success) to ease > understanding > * have clearly named constants (

Re: RFR: 8329581: Java launcher no longer prints a stack trace [v10]

> 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 issue linked above, > [LauncherHelper#getMainType](https://github.com/open

Re: RFR: 8331744: java.lang.classfile.TypeKind improvements [v4]

On Thu, 9 May 2024 12:29:40 GMT, Adam Sotona wrote: >> I actually am not sure of the reason; it is indeed a tableswitch in >> bytecode. @cl4es might know it better? > > Generally I agree with the API changes and with the > `descriptor.isPrimitive()` test before requesting a descriptor string. >

Re: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v31]

> 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: > - `Refer

Re: RFR: 8332003: Clarify javadoc for MemoryLayout::offsetHandle [v2]

On Thu, 9 May 2024 18:26:17 GMT, Maurizio Cimadamore wrote: >> Consider this layout: >> >> >> MemoryLayout SEQ = MemoryLayout.sequenceLayout(5, >> MemoryLayout.sequenceLayout(10, JAVA_INT)); >> >> >> And the corresponding offset handle: >> >> >> MethodHandle offsetHandle = SEQ

Re: RFR: 8332003: Clarify javadoc for MemoryLayout::offsetHandle [v2]

On Thu, 9 May 2024 18:26:17 GMT, Maurizio Cimadamore wrote: >> Consider this layout: >> >> >> MemoryLayout SEQ = MemoryLayout.sequenceLayout(5, >> MemoryLayout.sequenceLayout(10, JAVA_INT)); >> >> >> And the corresponding offset handle: >> >> >> MethodHandle offsetHandle = SEQ

Re: RFR: 8305457: Implement java.io.IO [v7]

> Please review this PR which introduces the `java.io.IO` top-level class and > three methods to `java.io.Console` for [Implicitly Declared Classes and > Instance Main Methods (Third Preview)]. > > This PR has been obtained as `git merge --squash` of a now obsolete [draft > PR]. > > [Implicitl

Re: RFR: 8332003: Clarify javadoc for MemoryLayout::offsetHandle [v2]

> Consider this layout: > > > MemoryLayout SEQ = MemoryLayout.sequenceLayout(5, > MemoryLayout.sequenceLayout(10, JAVA_INT)); > > > And the corresponding offset handle: > > > MethodHandle offsetHandle = SEQ.offsetHandle(PathElement.sequenceLayout(), > PathElement.sequenceLayout(

Re: RFR: 8331866: Add warnings for locale data dependence [v2]

On Thu, 9 May 2024 17:58:21 GMT, Naoto Sato wrote: >> In order to enlighten users to not depend on a particular version of the >> locale data, putting a note into the JDK vs. CLDR version chart would be >> appropriate. > > Naoto Sato has updated the pull request with a new target base due to a

Re: Status of ZIP64 InputStream bug JDK-8298530?

On Thu, May 9, 2024 at 12:43 PM Bernd Eckenfels wrote: > But this one here is still open: > > * [JDK-8298530] ZipInputStream.readEnd fails for certain ZIP64 archives > with small files - Java Bug System (openjdk.org) > > FWIW when I run the test case

Re: RFR: 8331866: Add warnings for locale data dependence [v2]

On Thu, 9 May 2024 17:58:34 GMT, Naoto Sato wrote: >> src/java.base/share/classes/java/util/spi/LocaleServiceProvider.java line >> 157: >> >>> 155: * Note that the CLDR locale data are subject to change. Users should >>> not assume >>> 156: * that the locale data remain the same across CLDR

Re: RFR: 8331866: Add warnings for locale data dependence [v2]

On Thu, 9 May 2024 17:58:21 GMT, Naoto Sato wrote: >> In order to enlighten users to not depend on a particular version of the >> locale data, putting a note into the JDK vs. CLDR version chart would be >> appropriate. > > Naoto Sato has updated the pull request with a new target base due to a

Re: RFR: 8331866: Add warnings for locale data dependence [v2]

On Thu, 9 May 2024 16:57:49 GMT, Joe Wang wrote: >> Naoto Sato 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 three additional >> commits since

Re: RFR: 8331866: Add warnings for locale data dependence [v2]

> In order to enlighten users to not depend on a particular version of the > locale data, putting a note into the JDK vs. CLDR version chart would be > appropriate. Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unr

Status of ZIP64 InputStream bug JDK-8298530?

Hello, I remember to have seen a few ZIP64 compatibility bug fixed in the past. But this one here is still open: * [JDK-8298530] ZipInputStream.readEnd fails for certain ZIP64 archives with small files - Java Bug System (openjdk.org) There seem to be unofficial patches. We seem to be bothered by th

Re: RFR: 8331866: Add warnings for locale data dependence

On Wed, 8 May 2024 20:21:50 GMT, Naoto Sato wrote: > In order to enlighten users to not depend on a particular version of the > locale data, putting a note into the JDK vs. CLDR version chart would be > appropriate. src/java.base/share/classes/java/util/spi/LocaleServiceProvider.java line 157:

Re: RFR: 8331876: JFR: Move file read and write events to java.base [v3]

On Thu, 9 May 2024 15:41:42 GMT, Erik Gahlin wrote: >> src/java.base/share/classes/jdk/internal/event/JFRTracing.java line 51: >> >>> 49: field.setAccessible(true); >>> 50: field.setBoolean(null, true); >>> 51: } >> >> Using reflection with `Field` seems expedient - a more modern

Re: RFR: 8305457: Implement java.io.IO [v6]

> Please review this PR which introduces the `java.io.IO` top-level class and > three methods to `java.io.Console` for [Implicitly Declared Classes and > Instance Main Methods (Third Preview)]. > > This PR has been obtained as `git merge --squash` of a now obsolete [draft > PR]. > > [Implicitl

Re: RFR: 8305457: Implement java.io.IO [v5]

On Thu, 9 May 2024 14:41:13 GMT, Jonathan Gibbons wrote: > (Minor). at least within the context of this PR, tags like `@param` and > `@throws` are stylistically inconsistent as to whether they begin with a > capital letter and end with a period. (I have not checked for local > consistency with

Integrated: 8329691: Support `nonlikelyScript` parent locale inheritance

On Mon, 6 May 2024 17:53:56 GMT, Naoto Sato wrote: > This PR is to implement the `nonlikelyScript` feature that went into CLDR > version 45 for migration purposes. In its release note, it states > (https://cldr.unicode.org/index/downloads/cldr-45): > > Migration > Changes to parentLocales requ

Re: RFR: 8331876: JFR: Move file read and write events to java.base [v3]

On Thu, 9 May 2024 14:29:13 GMT, Daniel Fuchs wrote: >> Erik Gahlin has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Move methods > > src/java.base/share/classes/jdk/internal/event/JFRTracing.java line 51: > >> 49: field.setAccessi

Re: RFR: 8332003: Clarify javadoc for MemoryLayout::offsetHandle

On Thu, 9 May 2024 15:00:35 GMT, Maurizio Cimadamore wrote: > Consider this layout: > > > MemoryLayout SEQ = MemoryLayout.sequenceLayout(5, > MemoryLayout.sequenceLayout(10, JAVA_INT)); > > > And the corresponding offset handle: > > > MethodHandle offsetHandle = SEQ.offsetHand

RFR: 8332003: Clarify javadoc for MemoryLayout::offsetHandle

Consider this layout: MemoryLayout SEQ = MemoryLayout.sequenceLayout(5, MemoryLayout.sequenceLayout(10, JAVA_INT)); And the corresponding offset handle: MethodHandle offsetHandle = SEQ.offsetHandle(PathElement.sequenceLayout(), PathElement.sequenceLayout()); The resulting meth

Re: RFR: 8331876: JFR: Move file read and write events to java.base [v3]

On Thu, 9 May 2024 14:25:27 GMT, Daniel Fuchs wrote: >> Erik Gahlin has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Move methods > > src/java.base/share/classes/java/io/FileInputStream.java line 63: > >> 61: private static final int

Withdrawn: 8327786: Add fluent setAccessible()

On Thu, 25 Jan 2024 21:35:45 GMT, Sergey wrote: > The feature allows to extract a private field value in a single expression, > like so: > > object.getClass().getDeclaredField().setAccessible().get(object) This pull request has been closed without being integrated. - PR: https://

Re: RFR: 8305457: Implement java.io.IO [v5]

On Thu, 9 May 2024 14:23:37 GMT, Pavel Rappo wrote: >> Please review this PR which introduces the `java.io.IO` top-level class and >> three methods to `java.io.Console` for [Implicitly Declared Classes and >> Instance Main Methods (Third Preview)]. >> >> This PR has been obtained as `git merge

Re: RFR: 8331876: JFR: Move file read and write events to java.base [v3]

On Thu, 9 May 2024 11:19:14 GMT, Erik Gahlin wrote: >> Hi, >> >> Could I have a review of a change that moves the jdk.FileRead and >> jdk.FileWrite events to java.base to remove the use of the ASM >> instrumentation. >> >> Testing: jdk/jdk/jfr >> >> Thanks >> Erik > > Erik Gahlin has updated

Re: RFR: 8305457: Implement java.io.IO [v5]

> Please review this PR which introduces the `java.io.IO` top-level class and > three methods to `java.io.Console` for [Implicitly Declared Classes and > Instance Main Methods (Third Preview)]. > > This PR has been obtained as `git merge --squash` of a now obsolete [draft > PR]. > > [Implicitl

Re: RFR: 8331932: Startup regressions in 23-b13 [v5]

On Thu, 9 May 2024 13:34:16 GMT, Claes Redestad wrote: >> A rather large startup regression was introduced in 23-b13 from >> [JDK-8309622](https://bugs.openjdk.org/browse/JDK-8309622). Some of that has >> been dealt with as enhancements such as >> [JDK-8330802](https://bugs.openjdk.org/browse/

Re: RFR: 8331932: Startup regressions in 23-b13 [v5]

> A rather large startup regression was introduced in 23-b13 from > [JDK-8309622](https://bugs.openjdk.org/browse/JDK-8309622). Some of that has > been dealt with as enhancements such as > [JDK-8330802](https://bugs.openjdk.org/browse/JDK-8330802), > [JDK-8330595](https://bugs.openjdk.org/brows

Re: RFR: 8310837: Use ByteArrayLittleEndian in java.util.zip [v8]

On Wed, 28 Feb 2024 14:21:16 GMT, Glavo wrote: >> Using `ByteArrayLittleEndian` is simpler and faster. >> >> `make test TEST="micro:java.util.zip.ZipFileOpen"`: >> >> >> Benchmark (size) Mode Cnt Score Error >> Units >> - ZipFileOpen.openCloseZipFile 512

Re: RFR: 8331744: java.lang.classfile.TypeKind improvements [v4]

On Thu, 9 May 2024 12:07:22 GMT, Chen Liang wrote: >> src/java.base/share/classes/java/lang/classfile/TypeKind.java line 139: >> >>> 137: case 'V' -> TypeKind.VoidType; >>> 138: default -> throw new IllegalArgumentException("Bad type: " >>> + s); >>> 139: }; >>

Re: RFR: 8331744: java.lang.classfile.TypeKind improvements [v4]

On Thu, 9 May 2024 07:23:16 GMT, Adam Sotona wrote: >> Chen Liang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Hash table, use fixed random seed > > src/java.base/share/classes/java/lang/classfile/TypeKind.java line 139: > >> 137:

Re: RFR: 8321274: Rename ZipEntry.extraAttributes to ZipEntry.externalFileAttributes [v4]

On Fri, 8 Mar 2024 09:34:05 GMT, Eirik Bjørsnøs wrote: >> Please consider this PR which suggests we rename `ZipEntry.extraAttributes` >> to `ZipEntry.externalFileAttributes`. >> >> This field was introduced in >> [JDK-8218021](https://bugs.openjdk.org/browse/JDK-8218021), originally under >>

Re: RFR: 8310837: Use ByteArrayLittleEndian in java.util.zip [v8]

On Wed, 28 Feb 2024 14:21:16 GMT, Glavo wrote: >> Using `ByteArrayLittleEndian` is simpler and faster. >> >> `make test TEST="micro:java.util.zip.ZipFileOpen"`: >> >> >> Benchmark (size) Mode Cnt Score Error >> Units >> - ZipFileOpen.openCloseZipFile 512

Re: RFR: 8331876: JFR: Move file read and write events to java.base [v3]

On Thu, 9 May 2024 07:33:22 GMT, Erik Gahlin wrote: >> src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 78: >> >>> 76: >>> 77: // Flag that determines if file reads/writes should be traced by JFR >>> 78: private static boolean jfrTracing; >> >> Should the force method b

Re: RFR: 8321274: Rename ZipEntry.extraAttributes to ZipEntry.externalFileAttributes [v4]

On Fri, 8 Mar 2024 09:34:05 GMT, Eirik Bjørsnøs wrote: >> Please consider this PR which suggests we rename `ZipEntry.extraAttributes` >> to `ZipEntry.externalFileAttributes`. >> >> This field was introduced in >> [JDK-8218021](https://bugs.openjdk.org/browse/JDK-8218021), originally under >>

Re: RFR: 8331876: JFR: Move file read and write events to java.base [v3]

> Hi, > > Could I have a review of a change that moves the jdk.FileRead and > jdk.FileWrite events to java.base to remove the use of the ASM > instrumentation. > > Testing: jdk/jdk/jfr > > Thanks > Erik Erik Gahlin has updated the pull request incrementally with one additional commit since t

Re: RFR: 8331535: Incorrect prompt for Console.readLine [v4]

On Tue, 7 May 2024 07:13:23 GMT, Jan Lahoda wrote: >> When JLine reads a line, there may be a prompt provided. However, JLine will >> not interpret the prompt literally, it will handle `%` specially. As a >> consequence, doing: >> >> System.console().readLine("%%s"); >> >> >> will not print

Re: RFR: 8331876: JFR: Move file read and write events to java.base [v2]

> Hi, > > Could I have a review of a change that moves the jdk.FileRead and > jdk.FileWrite events to java.base to remove the use of the ASM > instrumentation. > > Testing: jdk/jdk/jfr > > Thanks > Erik Erik Gahlin has updated the pull request incrementally with one additional commit since t

Re: RFR: 8320396: Class-File API ClassModel::verify should include checks from hotspot/share/classfile/classFileParser.cpp [v5]

> ClassFile API `jdk.internal.classfile.verifier.VerifierImpl` performed only > bytecode-level class verification. > This patch adds `jdk.internal.classfile.verifier.ParserVerifier` with > additional class checks inspired by > `hotspot/share/classfile/classFileParser.cpp`. > > Also new `Verifie

Re: RFR: 8320396: Class-File API ClassModel::verify should include checks from hotspot/share/classfile/classFileParser.cpp [v4]

On Tue, 7 May 2024 18:51:28 GMT, Chen Liang wrote: >> Adam Sotona has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 28 commits: >> >> - Merge branch 'master' into JDK-8320396-verifier-extension >> - added references to jvms >> -

Re: RFR: 8320396: Class-File API ClassModel::verify should include checks from hotspot/share/classfile/classFileParser.cpp [v4]

On Tue, 7 May 2024 18:50:28 GMT, Chen Liang wrote: >> Adam Sotona has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 28 commits: >> >> - Merge branch 'master' into JDK-8320396-verifier-extension >> - added references to jvms >> -

Re: RFR: 8320396: Class-File API ClassModel::verify should include checks from hotspot/share/classfile/classFileParser.cpp [v4]

On Tue, 7 May 2024 18:47:34 GMT, Chen Liang wrote: >> Adam Sotona has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 28 commits: >> >> - Merge branch 'master' into JDK-8320396-verifier-extension >> - added references to jvms >> -

Re: RFR: 8325679: Optimize ArrayList subList sort [v4]

On Mon, 19 Feb 2024 10:05:24 GMT, Attila Szegedi wrote: >> Somewhat surprisingly, `ArrayList$Sublist.sort()` is not specialized and >> will thus fall back to slower default method of `List.sort()` instead of >> sorting a range of the array in-place in its backing root `ArrayList`. >> >> This

Re: RFR: 8320396: Class-File API ClassModel::verify should include checks from hotspot/share/classfile/classFileParser.cpp [v4]

On Tue, 7 May 2024 18:42:24 GMT, Chen Liang wrote: >> Adam Sotona has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 28 commits: >> >> - Merge branch 'master' into JDK-8320396-verifier-extension >> - added references to jvms >> -

Re: RFR: 8320396: Class-File API ClassModel::verify should include checks from hotspot/share/classfile/classFileParser.cpp [v4]

On Tue, 7 May 2024 18:39:40 GMT, Chen Liang wrote: >> Adam Sotona has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 28 commits: >> >> - Merge branch 'master' into JDK-8320396-verifier-extension >> - added references to jvms >> -

Re: RFR: 8331646: Add specific regression leap year tests [v4]

> Calendar.add() tests that describe its behavior. serhiysachkov has updated the pull request incrementally with one additional commit since the last revision: JDK-8331646 updating impl according to review requests - Changes: - all: https://git.openjdk.org/jdk/pull/19082/files

Re: RFR: 8330205: Initial troff manpage generation for JDK 24

On Tue, 7 May 2024 11:53:19 GMT, Pavel Rappo wrote: > Please review this mechanical change to man pages. This PR should be > integrated after https://github.com/openjdk/jdk/pull/18787. I think we may have to restore this to a standalone start-of-release change done after the other start-of-rel

Re: RFR: 8330988: Implementation of 8288293: Windows/gcc Port for hsdis

On Wed, 24 Apr 2024 09:15:21 GMT, Magnus Ihse Bursie wrote: >> WIP >> >> This changeset contains hsdis for Windows/gcc Port. It supports both the >> binutils and capstone backends, though the LLVM backend is left out due to >> compatibility issues encountered during the build. Currently, which

Re: RFR: 8330988: Implementation of 8288293: Windows/gcc Port for hsdis [v2]

> WIP > > This changeset contains hsdis for Windows/gcc Port. It supports both the > binutils and capstone backends, though the LLVM backend is left out due to > compatibility issues encountered during the build. Currently, which gcc > distributions are supported is still to be clarified, as se

Re: RFR: 8330988: Implementation of 8288293: Windows/gcc Port for hsdis

On Wed, 24 Apr 2024 09:15:21 GMT, Magnus Ihse Bursie wrote: >> WIP >> >> This changeset contains hsdis for Windows/gcc Port. It supports both the >> binutils and capstone backends, though the LLVM backend is left out due to >> compatibility issues encountered during the build. Currently, which

Re: RFR: 8331876: JFR: Move file read and write events to java.base

On Thu, 9 May 2024 07:20:55 GMT, Alan Bateman wrote: >> Hi, >> >> Could I have a review of a change that moves the jdk.FileRead and >> jdk.FileWrite events to java.base to remove the use of the ASM >> instrumentation. >> >> Testing: jdk/jdk/jfr >> >> Thanks >> Erik > > src/java.base/share/cl

Re: RFR: 8331744: java.lang.classfile.TypeKind improvements [v4]

On Tue, 7 May 2024 15:23:10 GMT, Chen Liang wrote: >> A peek into TypeKind during the research for #19105 reveals that TypeKind >> has a few issues: >> 1. Name mismatch for `newarraycode` and `fromNewArrayCode`: Renamed both to >> use "newarray code" >> 2. `fromDescriptor` can throw IOOBE if th

Re: RFR: 8331876: JFR: Move file read and write events to java.base

On Tue, 7 May 2024 19:32:57 GMT, Erik Gahlin wrote: > Hi, > > Could I have a review of a change that moves the jdk.FileRead and > jdk.FileWrite events to java.base to remove the use of the ASM > instrumentation. > > Testing: jdk/jdk/jfr > > Thanks > Erik src/java.base/share/classes/sun/nio/

Re: RFR: 8311175: Move BufWriter::asByteBuffer to BufWriterImpl [v2]

On Tue, 7 May 2024 15:30:25 GMT, Chen Liang wrote: >> As discussed on the mailing list >> https://mail.openjdk.org/pipermail/classfile-api-dev/2023-June/000381.html, >> BufWriter::asByteBuffer has a behavior not suitable for API and is only used >> by internal StackMapGenerator/StackCounter, s