On Fri, 30 Aug 2024 10:51:59 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
> Return the final path derived from the string returned by `canonicalize0()`.
Brian Burkhalter has updated the pull request incrementally with one additional
commit since the last revision:
8003887: Free value allocated in and returned by getFinalPath()
-
Changes:
- all: https
On Fri, 30 Aug 2024 15:31:26 GMT, Francesco Nigro wrote:
> good point: relatively to the baseline, nope, cause the new version improve
> regardless, even when the new version got high branch misses
My feeling is that the intrinsic we have under the hood must be doing some
similar branching to
On Fri, 30 Aug 2024 20:59:18 GMT, Brian Burkhalter wrote:
> Return the final path derived from the string returned by `canonicalize0()`.
The variable `GetFinalPathNameByHandle_func` is removed from the native code as
we no longer care about Windows versions preceding Vista.
-
PR C
Return the final path derived from the string returned by `canonicalize0()`.
-
Commit messages:
- 8003887: File.getCanonicalFile() does not resolve symlinks on MS Windows
Changes: https://git.openjdk.org/jdk/pull/20801/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20801&r
On Fri, 30 Aug 2024 05:21:54 GMT, David Holmes wrote:
>> This is the implementation of a new method added to the JNI specification.
>>
>> From the CSR request:
>>
>> The `GetStringUTFLength` function returns the length as a `jint` (`jsize`)
>> value and so is limited to returning at most `Inte
On Wed, 28 Aug 2024 13:14:22 GMT, Yudi Zheng wrote:
>> Srinivas Vamsi Parasa has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Add stub initialization and extra tanh tests
>
> src/hotspot/share/jvmci/jvmciCompilerToVM.hpp line 114:
>
>> 1
On Tue, 27 Aug 2024 22:44:43 GMT, Joe Darcy wrote:
>>> This PR doesn't include any additional tests. It is often appropriate to
>>> add more regression testing when introducing a new implementation of a
>>> method.
>>
>> Thank You Joe for the suggestion. Will add more tests. (This PR passes th
> 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
Srinivas Vamsi Parasa has updated the pull request incrementally with
> Use fast path for ascii characters 1 to 127 to improve the performance of
> writing Utf8Entry to BufferWriter.
Shaojin Wen has updated the pull request incrementally with one additional
commit since the last revision:
optimize Utf8EntryImpl#writeTo(UTF)
-
Changes:
- all: htt
> Many constants are cluttered in `ClassFile`. However, only a few of them are
> ever used by regular users, most notably `ACC_` flags and `JAVA_X_VERSION`
> constants. All other constants are specific and should live in more local
> locations, such as getters that return these constants.
>
> T
On Fri, 30 Aug 2024 17:08:33 GMT, Shaojin Wen wrote:
>> Use fast path for ascii characters 1 to 127 to improve the performance of
>> writing Utf8Entry to BufferWriter.
>
> Shaojin Wen has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Suggest
On Fri, 23 Aug 2024 19:58:08 GMT, Justin Lu wrote:
> Please review this PR which clarifies that the matching order of format
> styles for MessageFormat sub formats is not guaranteed. A corresponding CSR
> has also been drafted.
>
> This is relevant when a locale provides equivalent patterns fo
> Please review this small documentation change to ConstantPoolBuilder to fix a
> typo and clarify the usage of the `constantValueEntry` method.
David M. Lloyd has updated the pull request incrementally with one additional
commit since the last revision:
Review comments
-
Change
On Tue, 27 Aug 2024 22:15:17 GMT, Chen Liang wrote:
> `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
On Fri, 30 Aug 2024 15:08:20 GMT, David M. Lloyd wrote:
> Please review this small documentation change to ConstantPoolBuilder to fix a
> typo and clarify the usage of the `constantValueEntry` method.
src/java.base/share/classes/java/lang/classfile/constantpool/ConstantPoolBuilder.java
line 47
On Fri, 2 Aug 2024 00:21:28 GMT, Brian Burkhalter wrote:
> Add some verbiage indicating that an `IOException` will be thrown if a file
> with a name generated from the supplied prefix and suffix according to the
> described algorithm cannot be generated by the underlying system, whether
> that
> Use fast path for ascii characters 1 to 127 to improve the performance of
> writing Utf8Entry to BufferWriter.
Shaojin Wen has updated the pull request incrementally with one additional
commit since the last revision:
Suggestions from @cl4es, rename hasNegativeOrZeros to isLatin1GreaterThan
On Thu, 29 Aug 2024 13:14:35 GMT, Magnus Ihse Bursie wrote:
> Currently, we issue -Wno-unused for all files in clang, 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 -Wal
On Fri, 30 Aug 2024 11:35:51 GMT, Magnus Ihse Bursie wrote:
>> Currently, we issue -Wno-unused for all files in clang, 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
On Fri, 30 Aug 2024 12:15:36 GMT, Per Minborg wrote:
>> @minborg Hi! I didn't checked the numbers with the benchmark I've written at
>> https://github.com/openjdk/jdk/pull/20712#discussion_r1732802685 which is
>> meant to stress the branch predictor (without enough `samples` i.e. past
>> 128K
On Fri, 30 Aug 2024 15:21:52 GMT, Maurizio Cimadamore
wrote:
> in this case, we can't optimize as well, because we have different branches
> which get taken or not in a less predictable fashion.
Exactly - It has been designed to show the case when the conditions materialize
(because are take
On Fri, 30 Aug 2024 12:15:36 GMT, Per Minborg wrote:
>> @minborg Hi! I didn't checked the numbers with the benchmark I've written at
>> https://github.com/openjdk/jdk/pull/20712#discussion_r1732802685 which is
>> meant to stress the branch predictor (without enough `samples` i.e. past
>> 128K
On Thu, 29 Aug 2024 22:11:36 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`
Please review this small documentation change to ConstantPoolBuilder to fix a
typo and clarify the usage of the `constantValueEntry` method.
-
Commit messages:
- 8339329: ConstantPoolBuilder#constantValueEntry method doc typo and
clarifications
Changes: https://git.openjdk.org/jdk
On Fri, 30 Aug 2024 05:24:58 GMT, Shaojin Wen wrote:
>> Use fast path for ascii characters 1 to 127 to improve the performance of
>> writing Utf8Entry to BufferWriter.
>
> Shaojin Wen has updated the pull request incrementally with one additional
> commit since the last revision:
>
> add com
On Fri, 30 Aug 2024 13:17:26 GMT, Emanuel Peter wrote:
>> Jatin Bhateja has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Adding descriptive comments
>
> src/hotspot/cpu/x86/matcher_x86.hpp line 215:
>
>> 213: }
>> 214:
>> 215: stati
On Thu, 29 Aug 2024 05:42:58 GMT, Jatin Bhateja wrote:
>> 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:-
>>
On Fri, 30 Aug 2024 10:51:59 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
On Wed, 31 Jul 2024 21:54:15 GMT, fitzsim wrote:
>> 8334048: -Xbootclasspath can not read some ZIP64 zip files
>
> fitzsim has updated the pull request incrementally with one additional commit
> since the last revision:
>
> BootClassPathZipFileTest: Switch to createClassBytes, createZip stati
On Fri, 30 Aug 2024 11:40:45 GMT, Severin Gehwolf wrote:
>> src/hotspot/share/prims/whitebox.cpp line 2507:
>>
>>> 2505: WB_END
>>> 2506:
>>> 2507: // Physical cpus of the host machine (including containers), Linux
>>> only.
>>
>> Isn't the comment a bit misleading ? From what I see , `
>>
On Fri, 30 Aug 2024 14:14:05 GMT, Severin Gehwolf wrote:
>> 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
>> c
On Fri, 30 Aug 2024 13:53:37 GMT, Francesco Nigro wrote:
> this can be u * 0xL if value != 0 and just 0L if not: not sure if
> fast(er), need to measure.
>
> Most of the time filling is happy with 0 since zeroing is the most common case
It's a clever trick. However, I was looking a
On Fri, 30 Aug 2024 12:15:36 GMT, Per Minborg wrote:
>> @minborg Hi! I didn't checked the numbers with the benchmark I've written at
>> https://github.com/openjdk/jdk/pull/20712#discussion_r1732802685 which is
>> meant to stress the branch predictor (without enough `samples` i.e. past
>> 128K
On Thu, 29 Aug 2024 22:33:34 GMT, Chen Liang wrote:
>> `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)
On Fri, 30 Aug 2024 10:51:59 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
> 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
On Fri, 30 Aug 2024 10:51:59 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
On Thu, 29 Aug 2024 22:33:34 GMT, Chen Liang wrote:
>> `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)
On Fri, 30 Aug 2024 11:44:09 GMT, Alan Bateman wrote:
> > The gnu.org docs cover this(concatenating gzip files) as part of its
> > [advanced usage of
> > gzip](https://github.com/openjdk/jdk/pull/20787#issuecomment-2320873616),
> > so I don'r think we need to do any more archeology
>
> Okay,
On Fri, 30 Aug 2024 11:46:51 GMT, Severin Gehwolf wrote:
> > Not saying that this is a very bad thing, maybe it is just the way it is,
> > that 'root' is needed ?
>
> I'll do some more research whether or not that is a hard requirement. Thanks
> for the comments so far.
It turns out it works
On Thu, 29 Aug 2024 16:03:31 GMT, Chen Liang wrote:
>> A very small optimization, split the large method inflate, split the
>> infrequently used paths into a method inflateCHAR
>
> src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java
> line 402:
>
>> 400:
On Thu, 29 Aug 2024 11:44:50 GMT, Shaojin Wen wrote:
> A very small optimization, split the large method inflate, split the
> infrequently used paths into a method inflateCHAR
Java's UTF8 entry cannot use the 4-byte format in regular UTF8. You can check
out how DataInputStream read UTF8 string
On Thu, 29 Aug 2024 11:44:50 GMT, Shaojin Wen wrote:
> A very small optimization, split the large method inflate, split the
> infrequently used paths into a method inflateCHAR
Typo (`HCAR` → `CHAR`):
src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java
line 235:
> 2
A very small optimization, split the large method inflate, split the
infrequently used paths into a method inflateCHAR
-
Commit messages:
- Update
src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java
- Update
src/java.base/share/classes/jdk/internal/clas
On Thu, 29 Aug 2024 21:49:58 GMT, Shaojin Wen wrote:
> A small optimization, optimize the BufferWriter implementation and use of
> ClassFile, provide faster patchInt and skip
src/java.base/share/classes/jdk/internal/classfile/impl/AbstractAttributeMapper.java
line 68:
> 66: BufWriterI
On Thu, 29 Aug 2024 21:49:58 GMT, Shaojin Wen wrote:
> A small optimization, optimize the BufferWriter implementation and use of
> ClassFile, provide faster patchInt and skip
I debugged the code and watched the compile log, patchInt calls are frequent.
For example, the following call stack:
On Thu, 29 Aug 2024 21:49:58 GMT, Shaojin Wen wrote:
> A small optimization, optimize the BufferWriter implementation and use of
> ClassFile, provide faster patchInt and skip
`patchInt` isn't that frequently used in workloads. I doubt this specialized
version provides much value; maybe @cl4es
A small optimization, optimize the BufferWriter implementation and use of
ClassFile, provide faster patchInt and skip
-
Commit messages:
- Suggestions from @cl4es
- fix build error
- remove BufWriter#patchInt
- optimize BufWriterImpl#patchInt
Changes: https://git.openjdk.org/jdk
On Wed, 28 Aug 2024 15:32:40 GMT, Francesco Nigro 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)
On Wed, 28 Aug 2024 22:41:59 GMT, Chen Liang wrote:
> In offline discussion, we agreed that current fields of `Opcode` violate data
> oriented design to a large extent. The attributes not generic to all opcode
> are removed.
>
> Up for preliminary review; needs to be reworked for #20737.
Look
On Fri, 30 Aug 2024 11:05:24 GMT, Matthias Baesken wrote:
> Not saying that this is a very bad thing, maybe it is just the way it is,
> that 'root' is needed ?
I'll do some more research whether or not that is a hard requirement. Thanks
for the comments so far.
-
PR Comment: http
On Fri, 30 Aug 2024 11:18:41 GMT, Lance Andersen wrote:
> The gnu.org docs cover this(concatenating gzip files) as part of its
> [advanced usage of
> gzip](https://github.com/openjdk/jdk/pull/20787#issuecomment-2320873616), so
> I don'r think we need to do any more archeology
Okay, but just v
On Fri, 30 Aug 2024 11:02:52 GMT, Matthias Baesken wrote:
>> Severin Gehwolf 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 10 additional
>> co
On Fri, 30 Aug 2024 11:18:41 GMT, Lance Andersen wrote:
>> I wonder if we can dig up the discussion on JDK-4691425. I can't find the
>> CSR (or "CCC" at the time) that would have captured the reasoning for
>> supporting this.
>
>> I wonder if we can dig up the discussion on JDK-4691425. I can't
On Thu, 29 Aug 2024 21:46:52 GMT, Chen Liang wrote:
>> `CodeBuilder::loadConstant(Opcode, ConstantDesc)` is error-prone and
>> confusing. Users should almost always use `loadConstant(ConstantDesc)` for
>> optimized instructions, or use specific factories `iconst_0` etc. or
>> `bipush` with arg
On Thu, 29 Aug 2024 13:14:35 GMT, Magnus Ihse Bursie wrote:
> Currently, we issue -Wno-unused for all files in clang, 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 -Wal
> Currently, we issue -Wno-unused for all files in clang, 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 s
On Fri, 30 Aug 2024 11:07:40 GMT, Alan Bateman wrote:
> I wonder if we can dig up the discussion on JDK-4691425. I can't find the CSR
> (or "CCC" at the time) that would have captured the reasoning for supporting
> this.
The gnu.org docs cover this(concatenating gzip files) as part of its [ad
On Fri, 30 Aug 2024 10:50:37 GMT, Eirik Bjørsnøs wrote:
>> Please review this PR with picks up on the excellent work done by
>> @archiecobbs in #18385
>>
>> The proposed changes aim to solve two issues with the current
>> `java.util.zip.GZIPInputStream`:
>>
>> * The class parses multiple con
On Wed, 28 Aug 2024 16:13:07 GMT, Severin Gehwolf wrote:
>> 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
>> c
On Wed, 28 Aug 2024 16:13:07 GMT, Severin Gehwolf wrote:
>> 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
>> c
On Mon, 26 Aug 2024 02:07:39 GMT, David Holmes wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Also update build to link properly
>
> I understand the cost overhead experienced by any individual Java run may
> 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 segments can be handled directly by Java code rather than
> tr
> Please review this PR with picks up on the excellent work done by
> @archiecobbs in #18385
>
> The proposed changes aim to solve two issues with the current
> `java.util.zip.GZIPInputStream`:
>
> * The class parses multiple concatenated GZIP files as a single stream. This
> behavior is not
Please review this PR with picks up on the excellent work done by @archiecobbs
in #18385
The proposed changes aim to solve two issues with the current
`java.util.zip.GZIPInputStream`:
* The class parses multiple concatenated GZIP files as a single stream. This
behavior is not documented in th
On Fri, 30 Aug 2024 07:27:11 GMT, Eirik Bjørsnøs wrote:
> Please review this PR with picks up on the excellent work done by
> @archiecobbs in #18385
>
> The proposed changes aim to solve two issues with the current
> `java.util.zip.GZIPInputStream`:
>
> * The class parses multiple concatenat
On Thu, 29 Aug 2024 13:55:25 GMT, Matthias Baesken wrote:
> We see HiddenClassUnloading.java failing on the ppc64 based platforms. On AIX
> it seems to fail always; Linux ppc64le sometimes.
> Failure output :
> java.lang.RuntimeException: unloadedClassCount is zero
> at HiddenClassUnloading.main
On Thu, 29 Aug 2024 13:55:25 GMT, Matthias Baesken wrote:
> We see HiddenClassUnloading.java failing on the ppc64 based platforms. On AIX
> it seems to fail always; Linux ppc64le sometimes.
> Failure output :
> java.lang.RuntimeException: unloadedClassCount is zero
> at HiddenClassUnloading.main
On Fri, 30 Aug 2024 09:09:57 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
On Wed, 21 Aug 2024 22:14:40 GMT, Magnus Ihse Bursie wrote:
>> As a preparation for Hermetic Java, we need to have a way to look up during
>> runtime if we are using a statically linked library or not.
>>
>> This change will be the first step needed towards compiling the object files
>> only o
On Thu, 29 Aug 2024 13:55:25 GMT, Matthias Baesken wrote:
> We see HiddenClassUnloading.java failing on the ppc64 based platforms. On AIX
> it seems to fail always; Linux ppc64le sometimes.
> Failure output :
> java.lang.RuntimeException: unloadedClassCount is zero
> at HiddenClassUnloading.main
On Fri, 30 Aug 2024 09:09:57 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
> 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 segments can be handled directly by Java code rather than
> tr
> 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 segments can be handled directly by Java code rather than
> tr
75 matches
Mail list logo
