Re: RFR: 8339217: Optimize ClassFile API loadConstant

On Thu, 29 Aug 2024 05:01:52 GMT, Shaojin Wen wrote: > This is a large method. By splitting it into multiple methods with the same > name, the caller can automatically select based on the different types of > parameters, avoiding this large call that cannot be inlined, which can also > improve

Re: RFR: 8339217: Optimize ClassFile API loadConstant

On Thu, 29 Aug 2024 05:11:36 GMT, Chen Liang wrote: >> This is a large method. By splitting it into multiple methods with the same >> name, the caller can automatically select based on the different types of >> parameters, avoiding this large call that cannot be inlined, which can also >> impr

RFR: 8339217: Optimize ClassFile API loadConstant

This is a large method. By splitting it into multiple methods with the same name, the caller can automatically select based on the different types of parameters, avoiding this large call that cannot be inlined, which can also improve startup performance. * current CodeBuilder { default Cod

Re: RFR: 8338023: Support two vector selectFrom API [v6]

On Tue, 27 Aug 2024 20:00:56 GMT, Paul Sandoz wrote: > My comment was related to understanding what `SelectFromTwoVectorNode::Ideal` > and `VectorRearrangeNode::Ideal` are doing - the former lowers, if needed, > into the rearrange expression and the latter adjusts, if needed, the index > vecto

Re: RFR: 8338023: Support two vector selectFrom API [v7]

> Hi All, > > As per the discussion on panama-dev mailing list[1], patch adds the support > for following new two vector permutation APIs. > > > Declaration:- > Vector.selectFrom(Vector v1, Vector v2) > > > Semantics:- > Using index values stored in the lanes of "this" vector, assembl

Re: RFR: 8338526: Don't store abstract and interface Klasses in class metaspace [v4]

On Wed, 28 Aug 2024 15:42:57 GMT, Coleen Phillimore wrote: >> This change stores InstanceKlass for interface and abstract classes in the >> non-class metaspace, since class metaspace will have limits on number of >> classes that can be represented when Lilliput changes go in. Classes that >>

Re: RFR: 8338017: Add AOT command-line flag aliases [v2]

On Thu, 29 Aug 2024 05:05:58 GMT, David Holmes wrote: >> Ioi Lam 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 five additional commits >> sinc

Re: RFR: 8338017: Add AOT command-line flag aliases [v2]

On Thu, 29 Aug 2024 04:24:02 GMT, Ioi Lam wrote: >> This is the 1st PR for [JEP 483: Ahead-of-Time Class Loading & >> Linking](https://bugs.openjdk.org/browse/JDK-8315737). >> >> Add the following command-line options as specified in JEP 483: >> >> >> - `-XX:AOTMode=off/record/create/auto/on`

Re: RFR: 8338017: Add AOT command-line flag aliases [v2]

> This is the 1st PR for [JEP 483: Ahead-of-Time Class Loading & > Linking](https://bugs.openjdk.org/browse/JDK-8315737). > > Add the following command-line options as specified in JEP 483: > > > - `-XX:AOTMode=off/record/create/auto/on` > - `-XX:AOTConfiguration=.aotconfig` > - `-XX:AOTCache=.

Re: RFR: 8339205: Optimize StackMapGenerator$Frame

On Wed, 28 Aug 2024 22:59:20 GMT, Shaojin Wen wrote: >> src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java >> line 1060: >> >>> 1058: if (desc == CD_void) throw new AssertionError("Should >>> not reach here"); >>> 1059: Type type; >>>

Re: RFR: 8339205: Optimize StackMapGenerator$Frame

On Wed, 28 Aug 2024 22:38:11 GMT, Chen Liang wrote: >> A small optimization to reduce the code size of StackMapGenerator.Frame's >> pushStack and setLocalsFromArg methods >> >> Below is the compiler log of C2 >> >> >> # baseline >> jdk.internal.classfile.impl.StackMapGenerator$Frame::pushStac

Re: RFR: 8339205: Optimize StackMapGenerator$Frame

On Wed, 28 Aug 2024 22:20:25 GMT, Shaojin Wen wrote: > A small optimization to reduce the code size of StackMapGenerator.Frame's > pushStack and setLocalsFromArg methods > > Below is the compiler log of C2 > > > # baseline > jdk.internal.classfile.impl.StackMapGenerator$Frame::pushStack (27 b

RFR: 8339205: Optimize StackMapGenerator$Frame

A small optimization to reduce the code size of StackMapGenerator.Frame's pushStack and setLocalsFromArg methods Below is the compiler log of C2 # baseline jdk.internal.classfile.impl.StackMapGenerator$Frame::pushStack (27 bytes) failed to inline: callee uses too much stack jdk.internal.clas

Integrated: 8338716: Re-visit "interrupt handling" in jdk.internal.loader.Resource

On Tue, 27 Aug 2024 21:57:16 GMT, Brent Christian wrote: > The InterruptibleIO feature (which was only on Solaris) was removed some time > ago. See [JDK-4385444](https://bugs.openjdk.org/browse/JDK-4385444). > > Vestiges of it remain in jdk.internal.loader.Resource.getBytes(), and should > be

Re: RFR: 8322256: Define and document GZIPInputStream concatenated stream semantics [v10]

> `GZIPInputStream` supports reading data from multiple concatenated GZIP data > streams since [JDK-4691425](https://bugs.openjdk.org/browse/JDK-4691425). In > order to do this, after a GZIP trailer frame is read, it attempts to read a > GZIP header frame and, if successful, proceeds onward to d

Withdrawn: 8339158: TypeKind add slotSize field

On Wed, 28 Aug 2024 10:26:58 GMT, Shaojin Wen wrote: > Small improvement, add a final field, no need to calculate every time. This pull request has been closed without being integrated. - PR: https://git.openjdk.org/jdk/pull/20743

Re: RFR: 8339115: Rename TypeKind enum constants to follow code style [v3]

> `TypeKind` enum constants are named in wrong code style; correct them before > finalization. > > Also improved `TypeKind` specification to talk about not mentioned > `returnType`, `void`, and subword types being erased to int (and how). See > the associated CSR too. > > See the HTML output f

Integrated: 8339126: JNI exception pending in Inflater.c

On Tue, 27 Aug 2024 21:26:52 GMT, Justin Lu wrote: > This PR addresses the JNI pending exception in Inflater.c, under > `Java_java_util_zip_Inflater_initIDs`. This pull request has now been integrated. Changeset: a8ac2872 Author:Justin Lu URL: https://git.openjdk.org/jdk/commit/a8a

Re: RFR: 8339126: JNI exception pending in Inflater.c

On Tue, 27 Aug 2024 21:26:52 GMT, Justin Lu wrote: > This PR addresses the JNI pending exception in Inflater.c, under > `Java_java_util_zip_Inflater_initIDs`. Thank you all for the reviews. - PR Comment: https://git.openjdk.org/jdk/pull/20735#issuecomment-2316262343

Re: RFR: 8339158: TypeKind add slotSize field

On Wed, 28 Aug 2024 10:26:58 GMT, Shaojin Wen wrote: > Small improvement, add a final field, no need to calculate every time. I think this is now part of #20737. - PR Comment: https://git.openjdk.org/jdk/pull/20743#issuecomment-2316262099

Re: RFR: 8339132: Make DirectCodeBuilder write through without allocating instruction objects [v3]

> Make `DirectCodeBuilder` write instructions actually directly without > allocating extra objects. This speed up a lot of simple Class-File building > cases that never go through intermediate transforms. Chen Liang has updated the pull request with a new target base due to a merge or a rebase.

Re: RFR: 8339115: Rename TypeKind enum constants to follow code style [v2]

> `TypeKind` enum constants are named in wrong code style; correct them before > finalization. > > Also improved `TypeKind` specification to talk about not mentioned > `returnType`, `void`, and subword types being erased to int (and how). See > the associated CSR too. > > See the HTML output f

Re: RFR: 8339132: Make DirectCodeBuilder write through without allocating instruction objects [v2]

On Wed, 28 Aug 2024 19:56:53 GMT, Chen Liang wrote: >> Make `DirectCodeBuilder` write instructions actually directly without >> allocating extra objects. This speed up a lot of simple Class-File building >> cases that never go through intermediate transforms. > > Chen Liang has updated the pull

Re: RFR: 8339196: Optimize BufWriterImpl#writeU1/U2/Int/Long

On Wed, 28 Aug 2024 13:16:03 GMT, Shaojin Wen wrote: > A small optimization makes BufWriterImpl's writeU1/U2/Int/Long methods more > C2-friendly and improves performance. Marked as reviewed by liach (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/20748#pullrequestreview-

Re: RFR: 8339196: Optimize BufWriterImpl#writeU1/U2/Int/Long

On Wed, 28 Aug 2024 13:16:03 GMT, Shaojin Wen wrote: > A small optimization makes BufWriterImpl's writeU1/U2/Int/Long methods more > C2-friendly and improves performance. src/java.base/share/classes/jdk/internal/classfile/impl/BufWriterImpl.java line 124: > 122: public void writeLong(long

RFR: 8339196: Optimize BufWriterImpl#writeU1/U2/Int/Long

A small optimization makes BufWriterImpl's writeU1/U2/Int/Long methods more C2-friendly and improves performance. - Commit messages: - refactor - optimize BufWriterImpl#writeU1/U2/Int/Long Changes: https://git.openjdk.org/jdk/pull/20748/files Webrev: https://webrevs.openjdk.org/

Re: RFR: 8339196: Optimize BufWriterImpl#writeU1/U2/Int/Long

On Wed, 28 Aug 2024 13:16:03 GMT, Shaojin Wen wrote: > A small optimization makes BufWriterImpl's writeU1/U2/Int/Long methods more > C2-friendly and improves performance. I made an off-list suggestion along this line some time before integration. IIRC it was a decent win back then, and with th

Re: RFR: 8339196: Optimize BufWriterImpl#writeU1/U2/Int/Long

On Wed, 28 Aug 2024 13:16:03 GMT, Shaojin Wen wrote: > A small optimization makes BufWriterImpl's writeU1/U2/Int/Long methods more > C2-friendly and improves performance. @liach Is this what you want to see? ## baseline @ 29 jdk.internal.classfile.impl.BufWriterImpl::writeU1 (8 bytes) in

Re: RFR: 8322256: Define and document GZIPInputStream concatenated stream semantics [v9]

On Wed, 28 Aug 2024 18:08:43 GMT, Archie Cobbs wrote: > Sounds good. How would you like to do that? > > E.g. we could just remove the words "In particular, some GZIP compression > tools function by partitioning the input, compressing each partition > separately, and then concatenating the resu

Re: RFR: 8339132: Make DirectCodeBuilder write through without allocating instruction objects [v2]

> Make `DirectCodeBuilder` write instructions actually directly without > allocating extra objects. This speed up a lot of simple Class-File building > cases that never go through intermediate transforms. Chen Liang has updated the pull request incrementally with one additional commit since the

Re: RFR: 8339120: Use more fine-granular gcc unused warnings [v6]

On Wed, 28 Aug 2024 15:17:52 GMT, Magnus Ihse Bursie wrote: >> Currently, we issue -Wno-unused for all files in gcc, which is a rather big >> sledgehammer to get rid of some warnings that proliferate in a few areas of >> the build. >> >> We should instead leave -Wunused turned on (as done by -

Re: RFR: 8339132: Make DirectCodeBuilder write through without allocating instruction objects

On Wed, 28 Aug 2024 01:49:21 GMT, Chen Liang wrote: > Make `DirectCodeBuilder` write instructions actually directly without > allocating extra objects. This speed up a lot of simple Class-File building > cases that never go through intermediate transforms. src/java.base/share/classes/java/lang

Re: RFR: 6426678: (spec) File.createTempFile(prefix, suffix, dir) needs clarification for illegal symbols in suffix [v2]

On Fri, 2 Aug 2024 08:44:38 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 6426678: having the generated name -> with the generated name > > src/java.base/share/classes/java/io/File.java line

Re: RFR: 8338716: Re-visit "interrupt handling" in jdk.internal.loader.Resource [v2]

On Wed, 28 Aug 2024 18:35:32 GMT, Brent Christian wrote: >> The InterruptibleIO feature (which was only on Solaris) was removed some >> time ago. See [JDK-4385444](https://bugs.openjdk.org/browse/JDK-4385444). >> >> Vestiges of it remain in jdk.internal.loader.Resource.getBytes(), and should >

Re: RFR: 8338716: Re-visit "interrupt handling" in jdk.internal.loader.Resource [v2]

On Wed, 28 Aug 2024 06:32:44 GMT, Alan Bateman wrote: >> Brent Christian has updated the pull request incrementally with one >> additional commit since the last revision: >> >> move getContentLength() inside try block > > src/java.base/share/classes/jdk/internal/loader/Resource.java line 89:

Re: RFR: 8338716: Re-visit "interrupt handling" in jdk.internal.loader.Resource [v2]

> The InterruptibleIO feature (which was only on Solaris) was removed some time > ago. See [JDK-4385444](https://bugs.openjdk.org/browse/JDK-4385444). > > Vestiges of it remain in jdk.internal.loader.Resource.getBytes(), and should > be removed. Brent Christian has updated the pull request incr

Integrated: 8339167: Remove AbstractPoolEntry.PrimitiveEntry to reduce boxing overheads

On Wed, 28 Aug 2024 14:27:45 GMT, Claes Redestad wrote: > Removing PrimitiveEntry reduces boxing/unboxing and removes a class. This pull request has now been integrated. Changeset: eff6d9cd Author:Claes Redestad URL: https://git.openjdk.org/jdk/commit/eff6d9cd23f9da8720a44ad628aa0a3

Re: RFR: 8339167: Remove AbstractPoolEntry.PrimitiveEntry to reduce boxing overheads [v2]

On Wed, 28 Aug 2024 17:51:52 GMT, Claes Redestad wrote: >> Removing PrimitiveEntry reduces boxing/unboxing and removes a class. > > Claes Redestad has updated the pull request incrementally with one additional > commit since the last revision: > > Wrong hash for FloatEntryImpl Thanks! -

Re: RFR: 8338897: Small startup regression remains after JDK-8309622 and JDK-8331932 [v2]

On Mon, 26 Aug 2024 14:00:22 GMT, Claes Redestad wrote: >> #14404 caused some startup regressions, where the main cause of startup >> increase in that change was due the use of - and the not very optimized >> state of - runtime bootstrapped switches. This was remedied by a series of >> optimiz

Integrated: 8338897: Small startup regression remains after JDK-8309622 and JDK-8331932

On Mon, 26 Aug 2024 13:30:18 GMT, Claes Redestad wrote: > #14404 caused some startup regressions, where the main cause of startup > increase in that change was due the use of - and the not very optimized state > of - runtime bootstrapped switches. This was remedied by a series of > optimizatio

Re: RFR: 8322256: Define and document GZIPInputStream concatenated stream semantics [v9]

On Wed, 28 Aug 2024 17:50:36 GMT, Lance Andersen wrote: >> Archie Cobbs has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Revert all functional changes, leaving only tests & Javadoc. > > src/java.base/share/classes/java/util/zip/GZIPInputS

Re: RFR: 8336895: BufferedReader doesn't read full \r\n line ending when it doesn't fit in buffer [v3]

On Wed, 28 Aug 2024 16:38:06 GMT, Brian Burkhalter wrote: >> src/java.base/share/classes/java/io/BufferedReader.java line 62: >> >>> 60: * replacing each DataInputStream with an appropriate BufferedReader. >>> 61: * >>> 62: * More than one instance of BufferedReader should not be used with

Re: RFR: 8336895: BufferedReader doesn't read full \r\n line ending when it doesn't fit in buffer [v3]

On Fri, 26 Jul 2024 22:32:40 GMT, Brian Burkhalter wrote: >> Add some verbiage stating that two buffered readers or input streams should >> not be used to read from the same reader or input stream, respectively. > > Brian Burkhalter has updated the pull request incrementally with one > addition

Re: RFR: 8336895: BufferedReader doesn't read full \r\n line ending when it doesn't fit in buffer [v3]

On Wed, 28 Aug 2024 14:49:24 GMT, Jaikiran Pai wrote: >> Brian Burkhalter has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 8336895: Modified verbiage per reviewer comment > > src/java.base/share/classes/java/io/BufferedInputStream.java li

Re: RFR: 8336895: BufferedReader doesn't read full \r\n line ending when it doesn't fit in buffer [v4]

> Add some verbiage stating that two buffered readers or input streams should > not be used to read from the same reader or input stream, respectively. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8336895: " Doing" -> " Doing

Re: RFR: 8339167: Remove AbstractPoolEntry.PrimitiveEntry to reduce boxing overheads [v2]

On Wed, 28 Aug 2024 17:51:52 GMT, Claes Redestad wrote: >> Removing PrimitiveEntry reduces boxing/unboxing and removes a class. > > Claes Redestad has updated the pull request incrementally with one additional > commit since the last revision: > > Wrong hash for FloatEntryImpl Marked as revi

Re: RFR: 8322256: Define and document GZIPInputStream concatenated stream semantics [v9]

On Sun, 11 Aug 2024 18:58:05 GMT, Archie Cobbs wrote: >> `GZIPInputStream` supports reading data from multiple concatenated GZIP data >> streams since [JDK-4691425](https://bugs.openjdk.org/browse/JDK-4691425). In >> order to do this, after a GZIP trailer frame is read, it attempts to read a >

Re: RFR: 8339167: Remove AbstractPoolEntry.PrimitiveEntry to reduce boxing overheads [v2]

> Removing PrimitiveEntry reduces boxing/unboxing and removes a class. Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Wrong hash for FloatEntryImpl - Changes: - all: https://git.openjdk.org/jdk/pull/20749/files -

Re: RFR: 8338526: Don't store abstract and interface Klasses in class metaspace [v4]

On Wed, 21 Aug 2024 21:32:15 GMT, Chen Liang wrote: >> I feel like making it ACC_INTERFACE might cause some error if there are no >> public nonstatic methods, which is the case with this class. I don't know >> what @liach your comment means, but this code got more complicated than it >> was wi

Re: RFR: 8338768: Introduce runtime lookup to check for static builds [v2]

On Tue, 27 Aug 2024 23:15:03 GMT, Jiangli Zhou wrote: >> And the discussion whether the checks are made "dynamically" or "statically" >> is too simplified to be really helpful. >> >> Currently, we compile two sets of all object files, with slightly different >> compiler arguments, one for dyna

Re: RFR: 8338526: Don't store abstract and interface Klasses in class metaspace [v4]

On Wed, 28 Aug 2024 15:42:57 GMT, Coleen Phillimore wrote: >> This change stores InstanceKlass for interface and abstract classes in the >> non-class metaspace, since class metaspace will have limits on number of >> classes that can be represented when Lilliput changes go in. Classes that >>

Re: RFR: 8339126: JNI exception pending in Inflater.c

On Tue, 27 Aug 2024 21:26:52 GMT, Justin Lu wrote: > This PR addresses the JNI pending exception in Inflater.c, under > `Java_java_util_zip_Inflater_initIDs`. Marked as reviewed by naoto (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/20735#pullrequestreview-2266833278

Re: RFR: 8339126: JNI exception pending in Inflater.c

On Tue, 27 Aug 2024 21:26:52 GMT, Justin Lu wrote: > This PR addresses the JNI pending exception in Inflater.c, under > `Java_java_util_zip_Inflater_initIDs`. Looks OK to me. - Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20735#pullrequestrev

Re: RFR: 8336895: BufferedReader doesn't read full \r\n line ending when it doesn't fit in buffer [v3]

On Fri, 26 Jul 2024 22:32:40 GMT, Brian Burkhalter wrote: >> Add some verbiage stating that two buffered readers or input streams should >> not be used to read from the same reader or input stream, respectively. > > Brian Burkhalter has updated the pull request incrementally with one > addition

Re: RFR: 8336895: BufferedReader doesn't read full \r\n line ending when it doesn't fit in buffer [v3]

On Wed, 28 Aug 2024 14:53:37 GMT, Jaikiran Pai wrote: >> Brian Burkhalter has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 8336895: Modified verbiage per reviewer comment > > src/java.base/share/classes/java/io/BufferedReader.java line 62

Re: RFR: 8339167: Remove AbstractPoolEntry.PrimitiveEntry to reduce boxing overheads

On Wed, 28 Aug 2024 14:27:45 GMT, Claes Redestad wrote: > Removing PrimitiveEntry reduces boxing/unboxing and removes a class. Changes requested by liach (Reviewer). src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java line 1079: > 1077: > 1078: FloatEntryIm

Re: RFR: 8338526: Don't store abstract and interface Klasses in class metaspace [v4]

On Wed, 28 Aug 2024 15:42:57 GMT, Coleen Phillimore wrote: >> This change stores InstanceKlass for interface and abstract classes in the >> non-class metaspace, since class metaspace will have limits on number of >> classes that can be represented when Lilliput changes go in. Classes that >>

Re: RFR: 8333446: Add tests for hierarchical container support [v5]

On Wed, 28 Aug 2024 14:21:09 GMT, Zdenek Zambersky wrote: > > > If I am not mistaken, new test requires, that testsuite is ran as > > > superuser (root). (Because it writes `/etc/systemd/system`, runs certain > > > systemd commands). Should test be skipped for non-root? > > > > > > Thanks! I

Re: RFR: 8333446: Add tests for hierarchical container support [v6]

> Please review this PR which adds test support for systemd slices so that bugs > like [JDK-8217338](https://bugs.openjdk.org/browse/JDK-8217338) can be > verified. The added test, `SystemdMemoryAwarenessTest` currently passes on > cgroups v1 and fails on cgroups v2 due to the way how > [JDK-82

Re: RFR: 8338021: Support saturating vector operators in VectorAPI [v2]

On Wed, 28 Aug 2024 00:12:26 GMT, Sandhya Viswanathan wrote: >> Hey @jaskarth , Central idea behind introducing VectorReinterpretNode after >> unsigned vector IR is to facilitate unboxing-boxing optimization, this >> explicit reinterpretation ensures type compatibility between value being >>

Re: RFR: 8339167: Remove AbstractPoolEntry.PrimitiveEntry to reduce boxing overheads

On Wed, 28 Aug 2024 14:33:38 GMT, Chen Liang wrote: >> Removing PrimitiveEntry reduces boxing/unboxing and removes a class. > > src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java > line 1044: > >> 1042: @Override >> 1043: void writeTo(BufWriterImpl po

Re: RFR: 8339167: Remove AbstractPoolEntry.PrimitiveEntry to reduce boxing overheads

On Wed, 28 Aug 2024 14:27:45 GMT, Claes Redestad wrote: > Removing PrimitiveEntry reduces boxing/unboxing and removes a class. src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java line 1044: > 1042: @Override > 1043: void writeTo(BufWriterImpl pool) {

RFR: 8339167: Remove AbstractPoolEntry.PrimitiveEntry to reduce boxing overheads

Removing PrimitiveEntry reduces boxing/unboxing and removes a class. - Commit messages: - Revert tag rewrite - Remove AbstractPoolEntry.PrimitiveEntry to reduce boxing overheads Changes: https://git.openjdk.org/jdk/pull/20749/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr

Re: RFR: 8338526: Don't store abstract and interface Klasses in class metaspace [v3]

On Wed, 28 Aug 2024 05:57:14 GMT, Ioi Lam wrote: >> Coleen Phillimore has updated the pull request with a new target base due to >> a merge or a rebase. The pull request now contains four commits: >> >> - With JDK-8338929 we don't need is_in_class_space(). >> - Merge branch 'master' into anon

Re: RFR: 8338526: Don't store abstract and interface Klasses in class metaspace [v4]

> This change stores InstanceKlass for interface and abstract classes in the > non-class metaspace, since class metaspace will have limits on number of > classes that can be represented when Lilliput changes go in. Classes that > have no instances created for them don't require compressed class

Re: RFR: 8338967: Improve performance for MemorySegment::fill [v5]

On Wed, 28 Aug 2024 09:06:48 GMT, Per Minborg wrote: >> How fast do we need to be here given we are measuring in a few nanoseconds >> per operation? >> >> What if the goal is not to regress from say explicitly filling in a small >> sized segment or a comparable array (e.g., < 8 bytes) then ma

Re: RFR: 8339120: Use more fine-granular gcc unused warnings [v6]

On Wed, 28 Aug 2024 15:17:52 GMT, Magnus Ihse Bursie wrote: >> Currently, we issue -Wno-unused for all files in gcc, which is a rather big >> sledgehammer to get rid of some warnings that proliferate in a few areas of >> the build. >> >> We should instead leave -Wunused turned on (as done by -

Re: RFR: 8338967: Improve performance for MemorySegment::fill [v7]

On Wed, 28 Aug 2024 11:10:05 GMT, Per Minborg wrote: >> The performance of the `MemorySegment::fil` can be improved by replacing the >> `checkAccess()` method call with calling `checkReadOnly()` instead (as the >> bounds of the segment itself do not need to be checked). >> >> Also, smaller seg

Integrated: 8338729: Retire the test jdk/java/util/zip/TestZipError.java

On Wed, 21 Aug 2024 09:59:38 GMT, Eirik Bjørsnøs wrote: > Please review this test-only, cleanup PR which proposes that we retire the > `jdk/java/util/zip/TestZipError.java` test. > > The test has fallen out of sync with its original and stated purpose > described by its name, `@summary` tag an

Re: RFR: 8339120: Use more fine-granular gcc unused warnings [v6]

> Currently, we issue -Wno-unused for all files in gcc, which is a rather big > sledgehammer to get rid of some warnings that proliferate in a few areas of > the build. > > We should instead leave -Wunused turned on (as done by -Wall) and use a much > more fine-grained approach to disabling spe

Re: RFR: 8339120: Use more fine-granular gcc unused warnings [v6]

On Wed, 28 Aug 2024 15:15:03 GMT, Magnus Ihse Bursie wrote: >> Currently, we issue -Wno-unused for all files in gcc, which is a rather big >> sledgehammer to get rid of some warnings that proliferate in a few areas of >> the build. >> >> We should instead leave -Wunused turned on (as done by -

Re: RFR: 8336843: Deprecate java.util.zip.ZipError for removal

On Sun, 25 Aug 2024 13:36:18 GMT, Lance Andersen wrote: >> I think linking to the CSR would be fine, but there is no prerequisite for >> API specs to link to CSRs. Need @jddarcy to double check here. I was >> emulating `Thread.stop`: >> https://github.com/openjdk/jdk/blob/5671f836039ef1683e3e9

Re: RFR: 8339120: Use more fine-granular gcc unused warnings [v5]

> Currently, we issue -Wno-unused for all files in gcc, which is a rather big > sledgehammer to get rid of some warnings that proliferate in a few areas of > the build. > > We should instead leave -Wunused turned on (as done by -Wall) and use a much > more fine-grained approach to disabling spe

Re: RFR: 8339120: Use more fine-granular gcc unused warnings [v5]

On Wed, 28 Aug 2024 12:29:36 GMT, Magnus Ihse Bursie wrote: >> Good point, I'll try that. > > It turned out to be sort-of okay-ish. I explicitly listed like 6 or so > per-file exclusions in Hotspot (even though my normal cutoff for just setting > a component-wide exclude is 3-4) since it seems

Re: RFR: 8339120: Use more fine-granular gcc unused warnings [v3]

On Wed, 28 Aug 2024 13:35:19 GMT, Kim Barrett wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Fix aarch54 > > make/modules/java.desktop/lib/ClientLibraries.gmk line 284: > >> 282: >> 283: ifeq ($(USE_EXTERN

Re: RFR: 8339120: Use more fine-granular gcc unused warnings [v4]

> Currently, we issue -Wno-unused for all files in gcc, which is a rather big > sledgehammer to get rid of some warnings that proliferate in a few areas of > the build. > > We should instead leave -Wunused turned on (as done by -Wall) and use a much > more fine-grained approach to disabling spe

Re: RFR: 8336895: BufferedReader doesn't read full \r\n line ending when it doesn't fit in buffer [v3]

On Fri, 26 Jul 2024 22:32:40 GMT, Brian Burkhalter wrote: >> Add some verbiage stating that two buffered readers or input streams should >> not be used to read from the same reader or input stream, respectively. > > Brian Burkhalter has updated the pull request incrementally with one > addition

RFR: 8339168: Optimize ClassFile Util slotSize

A small optimization to improve the performance of jdk.internal.classfile.impl.Util#slotSize/isDoubleSlot - Commit messages: - optimize slotSize & isDoubleSlot Changes: https://git.openjdk.org/jdk/pull/20747/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20747&range=00

Re: RFR: 8339168: Optimize ClassFile Util slotSize

On Wed, 28 Aug 2024 13:12:35 GMT, Shaojin Wen wrote: > A small optimization to improve the performance of > jdk.internal.classfile.impl.Util#slotSize/isDoubleSlot Nice optimization enabled by our PrimitiveClassDesc object sharing. - Marked as reviewed by liach (Reviewer). PR Revi

Re: RFR: 8338729: Retire the test jdk/java/util/zip/TestZipError.java

On Wed, 21 Aug 2024 09:59:38 GMT, Eirik Bjørsnøs wrote: > Please review this test-only, cleanup PR which proposes that we retire the > `jdk/java/util/zip/TestZipError.java` test. > > The test has fallen out of sync with its original and stated purpose > described by its name, `@summary` tag an

Re: RFR: 8336843: Deprecate java.util.zip.ZipError for removal [v3]

On Wed, 28 Aug 2024 08:11:08 GMT, Eirik Bjørsnøs wrote: >> Please review this PR which suggests to deprecate the unused class >> `java.util.zip.ZipError` for removal. >> >> The class has been unsed by OpenJDK since the ZIP API was rewritten from >> native to Java in JDK 9. >> >> I opted to n

Re: [External] : Re: New candidate JEP: 484: Class-File API

Hi Adam, My apologies, this was a misunderstanding on my part. I think I misread this comment and didn't notice the word "preview": Unfortunately, ClassFile API's scope is only to interpret correctly the > Class Files that

Re: RFR: 8333446: Add tests for hierarchical container support [v5]

On Tue, 27 Aug 2024 15:01:59 GMT, Severin Gehwolf wrote: > > If I am not mistaken, new test requires, that testsuite is ran as superuser > > (root). (Because it writes `/etc/systemd/system`, runs certain systemd > > commands). Should test be skipped for non-root? > > Thanks! I can add that. FW

Re: RFR: 8338694: x86_64 intrinsic for tanh using libm

On Tue, 27 Aug 2024 22:23:44 GMT, Srinivas Vamsi Parasa wrote: >> I agree, this is all rather obscure. Ideally the same names that are used in >> wherever this comes from. >> >> Where does the algorithm come from? What are its accuracy guarantees? >> >> In addition, given the rarity of hyperb

Re: RFR: 8336843: Deprecate java.util.zip.ZipError for removal [v3]

On Wed, 28 Aug 2024 08:11:08 GMT, Eirik Bjørsnøs wrote: >> Please review this PR which suggests to deprecate the unused class >> `java.util.zip.ZipError` for removal. >> >> The class has been unsed by OpenJDK since the ZIP API was rewritten from >> native to Java in JDK 9. >> >> I opted to n

Re: RFR: 8339158: TypeKind add slotSize field

On Wed, 28 Aug 2024 10:26:58 GMT, Shaojin Wen wrote: > Small improvement, add a final field, no need to calculate every time. That kind of code is hard to understand. How simple is it to add a field！ - PR Comment: https://git.openjdk.org/jdk/pull/20743#issuecomment-2315436832

Re: RFR: 8339158: TypeKind add slotSize field

On Wed, 28 Aug 2024 10:26:58 GMT, Shaojin Wen wrote: > Small improvement, add a final field, no need to calculate every time. What if we reorder the constants to be like: VOID, REFERENCE, DOUBLE, LONG, FLOAT, INT, SHORT, CHAR, BYTE, BOOLEAN; and check like: int i = ordinal(); return i < 3 ? i

Re: RFR: 8338768: Introduce runtime lookup to check for static builds [v2]

On Mon, 26 Aug 2024 02:07:39 GMT, David Holmes wrote: > I understand the cost overhead experienced by any individual Java run may be > lost in the noise, but it still impacts every single Java run just to save > some time/resources for the handful of builders of statically linked VMs. I > am n

Re: RFR: 8336881: [Linux] Support for hierarchical limits for Metrics [v4]

> Please review this fix for cgroups-based metrics reporting in the > `jdk.internal.platform` package. This fix is supposed to address wrong > reporting of certain limits if the limits aren't set at the leaf nodes. > > For example, on cg v2, the memory limit interface file is `memory.max`. > Co

Re: RFR: 8339120: Use more fine-granular gcc unused warnings [v3]

On Wed, 28 Aug 2024 13:02:55 GMT, Magnus Ihse Bursie wrote: >> Currently, we issue -Wno-unused for all files in gcc, which is a rather big >> sledgehammer to get rid of some warnings that proliferate in a few areas of >> the build. >> >> We should instead leave -Wunused turned on (as done by -

Re: RFR: 8338694: x86_64 intrinsic for tanh using libm

On Wed, 21 Aug 2024 00:25:03 GMT, Srinivas Vamsi Parasa wrote: > The goal of this PR is to implement an x86_64 intrinsic for > java.lang.Math.tanh() using libm > > Benchmark (ops/ms) | Stock JDK | Tanh intrinsic | Speedup > -- | -- | -- | -- > MathBench.tanhDouble | 70900 | 95618 | 1.35x src/

Re: RFR: 8339120: Use more fine-granular gcc unused warnings [v3]

> Currently, we issue -Wno-unused for all files in gcc, which is a rather big > sledgehammer to get rid of some warnings that proliferate in a few areas of > the build. > > We should instead leave -Wunused turned on (as done by -Wall) and use a much > more fine-grained approach to disabling spe

Re: RFR: 8338768: Introduce runtime lookup to check for static builds [v2]

On Tue, 27 Aug 2024 23:15:03 GMT, Jiangli Zhou wrote: >> And the discussion whether the checks are made "dynamically" or "statically" >> is too simplified to be really helpful. >> >> Currently, we compile two sets of all object files, with slightly different >> compiler arguments, one for dyna

Re: RFR: 8339120: Use more fine-granular gcc unused warnings [v2]

On Wed, 28 Aug 2024 11:26:01 GMT, Magnus Ihse Bursie wrote: >> make/autoconf/flags-cflags.m4 line 239: >> >>> 237: # Additional warnings that are not activated by -Wall and -Wextra >>> 238: WARNINGS_ENABLE_ADDITIONAL="-Wpointer-arith -Wreturn-type >>> -Wsign-compare \ >>> 239:

Re: RFR: 8339120: Use more fine-granular gcc unused warnings [v2]

> Currently, we issue -Wno-unused for all files in gcc, which is a rather big > sledgehammer to get rid of some warnings that proliferate in a few areas of > the build. > > We should instead leave -Wunused turned on (as done by -Wall) and use a much > more fine-grained approach to disabling spe

Re: RFR: 8339158: TypeKind add slotSize field

On Wed, 28 Aug 2024 10:26:58 GMT, Shaojin Wen wrote: > Small improvement, add a final field, no need to calculate every time. Of course, the implementation complexity of these two is different, and the code size is also different. ## codeSize # baseline java.lang.classfile.TypeKind::slotSize

Re: RFR: 8339158: TypeKind add slotSize field

On Wed, 28 Aug 2024 10:26:58 GMT, Shaojin Wen wrote: > Small improvement, add a final field, no need to calculate every time. Is this field access faster than a table switch? Also notice there's #20737 which may come before your improvement. - PR Comment: https://git.openjdk.org/j

RFR: 8339158: TypeKind add slotSize field

Small improvement, add a final field, no need to calculate every time. - Commit messages: - slotSize field Changes: https://git.openjdk.org/jdk/pull/20743/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20743&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8339158 S

RFR: 8339154: Cleanups and JUnit conversion of test/jdk/java/util/zip/Available.java

Please review this test-only PR which addresses several issues with the `test/jdk/java/util/zip/Available.java` test: * The test is converted to JUnit 5 * The test now creates its own test vector programmatically instead of relying on a binary `input.jar` test vector * Coverage is added for ca

Re: RFR: 8338967: Improve performance for MemorySegment::fill [v5]

On Wed, 28 Aug 2024 09:06:48 GMT, Per Minborg wrote: > then maybe a loop suffices and the code is simple? We have tried a loop, but sadly the performance is not great if the number of iteration is small. This is due to the fact that long loops are split into two loops, and outer and an inner,

  1   2   >