On Tue, 3 Sep 2024 06:16:06 GMT, David Holmes wrote:
>>> Also doesn't a call like this trigger the warning about ignoring a function
>>> result, or have we disabled that one?
>>
>> Such a warning would be horrible to have enable. Then you would have to read
>> the value of every function that
On Tue, 3 Sep 2024 06:01:15 GMT, Alan Bateman wrote:
>> David Holmes has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> The JNI version update was incompete
>
> Marked as reviewed by alanb (Reviewer).
Thanks @AlanBateman !
-
On Tue, 3 Sep 2024 05:52:31 GMT, Magnus Ihse Bursie wrote:
>> This code is devoid of pretty much all error handling and logging, but I
>> agree that a simple fprintf on error would be useful.
>> Also doesn't a call like this trigger the warning about ignoring a function
>> result, or have we di
On Tue, 3 Sep 2024 03:00:56 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 `Integ
On Tue, 3 Sep 2024 02:25:16 GMT, David Holmes wrote:
> Also doesn't a call like this trigger the warning about ignoring a function
> result, or have we disabled that one?
Such a warning would be horrible to have enable. Then you would have to read
the value of every function that thought it sh
> 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 `Integer.MAX_VALUE`. But a Java
> string can itself consist of `In
On Fri, 30 Aug 2024 20:45:11 GMT, Chris Plummer wrote:
>> David Holmes has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Exclude test on 32-bit
>
> Overall it looks good to me, although I don't have experience adding a new
> JNI API (the
On Mon, 2 Sep 2024 22:32:34 GMT, Magnus Ihse Bursie wrote:
>> Matthias Baesken has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> adjust indentation in X11Color.c
>
> src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c line 744:
On Tue, 3 Sep 2024 00:38:40 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 two additional
> commits since the last revision:
>
> - code s
> 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 two additional
commits since the last revision:
- code style
- remove unsafe
-
Changes:
- all: https://g
> 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:
bug fix countGreaterThanZero
-
Changes:
- all: https://gi
On Mon, 2 Sep 2024 13:25:51 GMT, Matthias Baesken wrote:
>> We get a couple of warnings as errors on AIX because of unused variables or
>> functions , for example :
>> /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c
On Mon, 2 Sep 2024 20:06:06 GMT, Martin Doerr wrote:
>> Matthias Baesken has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> adjust indentation in X11Color.c
>
> src/java.desktop/unix/native/common/awt/X11Color.c line 1234:
>
>> 1232: awt_a
Thanks. Glad to see this finally land. That slidingWindow and other related
functions are extremely powerful.
On Mon, Sep 2, 2024 at 3:13 PM Mark Reinhold
wrote:
> https://openjdk.org/jeps/485
>
> Summary: Enhance the Stream API to support custom intermediate
> operations. This will allow s
On Mon, 2 Sep 2024 13:25:51 GMT, Matthias Baesken wrote:
>> We get a couple of warnings as errors on AIX because of unused variables or
>> functions , for example :
>> /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c
On Mon, 2 Sep 2024 15:27:59 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:
>
> typo
Th
https://openjdk.org/jeps/485
Summary: Enhance the Stream API to support custom intermediate
operations. This will allow stream pipelines to transform data in ways
that are not easily achievable with the existing built-in intermediate
operations.
- Mark
On Mon, 2 Sep 2024 15:27:59 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:
>
> typo
sr
On Mon, 2 Sep 2024 16:19:01 GMT, fabioromano1 wrote:
>> This implementation of MutableBigInteger.leftShift(int) optimizes the
>> current version, avoiding unnecessary copy of the MutableBigInteger's value
>> content and performing the primitive shifting only in the original portion
>> of the v
On Sun, 1 Sep 2024 16:32:00 GMT, fabioromano1 wrote:
>> This implementation of MutableBigInteger.leftShift(int) optimizes the
>> current version, avoiding unnecessary copy of the MutableBigInteger's value
>> content and performing the primitive shifting only in the original portion
>> of the v
On Mon, 2 Sep 2024 16:34:07 GMT, Raffaello Giulietti
wrote:
> Right, I didn't remember that `BigInteger` has its own implementation.
>
> However, reducing `MutableBigIntegerBox` to just a bunch of accessors to use
> in the unit test and the benchmarks should still be possible. Then having two
> This implementation of MutableBigInteger.leftShift(int) optimizes the current
> version, avoiding unnecessary copy of the MutableBigInteger's value content
> and performing the primitive shifting only in the original portion of the
> value array rather than in the value yet extended with trail
On Mon, 2 Sep 2024 16:19:01 GMT, fabioromano1 wrote:
>> This implementation of MutableBigInteger.leftShift(int) optimizes the
>> current version, avoiding unnecessary copy of the MutableBigInteger's value
>> content and performing the primitive shifting only in the original portion
>> of the v
On Mon, 2 Sep 2024 16:04:14 GMT, Raffaello Giulietti
wrote:
> * I wonder if `MutableBigIntegerBox` can be reduced to just a set of
> accessors for the `MutableBigInteger` fields. Also, I guess that the
> benchmarks can be written to use the public class `BigInteger` to avoid
> having two copi
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 18:46:08 GMT, Chen Liang wrote:
>> Shaojin Wen has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Suggestions from @cl4es, rename hasNegativeOrZeros to
>> isLatin1GreaterThanZero
>
> If a non-ascii is in the middle or t
> 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:
typo
-
Changes:
- all: https://git.openjdk.org/jdk/pull/2
> 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:
suggestion from @liach
-
Changes:
- all: https://git.open
On Mon, 2 Sep 2024 15:11:56 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:
>
> suggesti
> 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:
suggestion from @liach
-
Changes:
- all: https://git.open
On Mon, 2 Sep 2024 14:50:33 GMT, Shaojin Wen wrote:
>> BytecodeHelpers' loadOpcode and storeOpcode are large methods with code size
>> greater than 325, break it into multiple small methods and call them
>> directly in DirectCodeBuilder
>
> Shaojin Wen has updated the pull request incrementally
> BytecodeHelpers' loadOpcode and storeOpcode are large methods with code size
> greater than 325, break it into multiple small methods and call them directly
> in DirectCodeBuilder
Shaojin Wen has updated the pull request incrementally with one additional
commit since the last revision:
sug
On Mon, 2 Sep 2024 14:06:42 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 with a new target base due to a
> merge or a rebase. The incremental webrev exclude
On Mon, 2 Sep 2024 14:01:36 GMT, Shaojin Wen wrote:
>> src/java.base/share/classes/jdk/internal/classfile/impl/BytecodeHelpers.java
>> line 61:
>>
>>> 59: return switch (tk) {
>>> 60: case INT, SHORT, BYTE, CHAR, BOOLEAN
>>> 61:-> iload(slot);
>>
On Wed, 28 Aug 2024 04:14:53 GMT, Shaojin Wen wrote:
> BytecodeHelpers' loadOpcode and storeOpcode are large methods with code size
> greater than 325, break it into multiple small methods and call them directly
> in DirectCodeBuilder
src/java.base/share/classes/jdk/internal/classfile/impl/Dir
On Wed, 28 Aug 2024 04:14:53 GMT, Shaojin Wen wrote:
> BytecodeHelpers' loadOpcode and storeOpcode are large methods with code size
> greater than 325, break it into multiple small methods and call them directly
> in DirectCodeBuilder
src/java.base/share/classes/jdk/internal/classfile/impl/Byt
On Mon, 2 Sep 2024 13:02:40 GMT, Chen Liang wrote:
>> BytecodeHelpers' loadOpcode and storeOpcode are large methods with code size
>> greater than 325, break it into multiple small methods and call them
>> directly in DirectCodeBuilder
>
> src/java.base/share/classes/jdk/internal/classfile/impl
On Wed, 28 Aug 2024 04:14:53 GMT, Shaojin Wen wrote:
> BytecodeHelpers' loadOpcode and storeOpcode are large methods with code size
> greater than 325, break it into multiple small methods and call them directly
> in DirectCodeBuilder
@cl4es @liach Is there a better way to ensure that Opcode h
BytecodeHelpers' loadOpcode and storeOpcode are large methods with code size
greater than 325, break it into multiple small methods and call them directly
in DirectCodeBuilder
-
Commit messages:
- suggestion from @liach
- copyright
- direct call
- Break up large methods into sma
On Fri, 30 Aug 2024 19:39:32 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:
>
> optimiz
> 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 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
On Mon, 2 Sep 2024 14:03:55 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 with a new target base due to a
> merge or a rebase. The incremental webrev exclude
On Fri, 30 Aug 2024 19:39:32 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:
>
> optimiz
On Mon, 2 Sep 2024 12:17:57 GMT, Christoph Langer wrote:
>> Matthias Baesken has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> adjust indentation in X11Color.c
>
> src/java.desktop/unix/native/common/awt/X11Color.c line 1236:
>
>> 1234:
On Mon, 2 Sep 2024 11:43:20 GMT, Matthias Baesken wrote:
> We get a couple of warnings as errors on AIX because of unused variables or
> functions , for example :
> /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:66
> We get a couple of warnings as errors on AIX because of unused variables or
> functions , for example :
> /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:665:10:
> error: unused variable 'exePath' [-Werror,-Wunused
On Mon, 2 Sep 2024 10:03:59 GMT, Adam Sotona wrote:
> ClassFile API use an alternate labels inflation method for class versions <
> 50 (where StackMapTable attribute is optional).
> The alternate method missed label inflation of lookup switch and table switch
> instructions.
> This patch fixes
On Mon, 2 Sep 2024 12:30:43 GMT, Julian Waters wrote:
> Ah, the joys of supporting a platform that isn't covered by the Actions
> compile and test safety net :)
A Linux/clang build in the GHA would have probably shown at least a part of
those errors.
-
PR Comment: https://git.ope
On Mon, 2 Sep 2024 11:43:20 GMT, Matthias Baesken wrote:
> We get a couple of warnings as errors on AIX because of unused variables or
> functions , for example :
> /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:66
On Wed, 28 Aug 2024 16:05:45 GMT, Sandhya Viswanathan
wrote:
>> Wonder if it would have been simpler if we added unsigned vector operators
>> like Op_SaturatingUnsignedAddVB etc. We are not adding unsigned data types
>> to Java, only supporting unsigned (saturating) operations on existing sign
On Mon, 26 Aug 2024 22:17:55 GMT, Sandhya Viswanathan
wrote:
>> Jatin Bhateja has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Review comments resolutions.
>
> src/hotspot/cpu/x86/assembler_x86.cpp line 10229:
>
>> 10227: InstructionM
> Hi All,
>
> As per the discussion on panama-dev mailing list[1], patch adds the support
> following new vector operators.
>
>
> . SUADD : Saturating unsigned addition.
> . SADD: Saturating signed addition.
> . SUSUB : Saturating unsigned subtraction.
> . SSUB:
On Mon, 2 Sep 2024 11:43:20 GMT, Matthias Baesken wrote:
> We get a couple of warnings as errors on AIX because of unused variables or
> functions , for example :
> /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:66
We get a couple of warnings as errors on AIX because of unused variables or
functions , for example :
/priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:665:10:
error: unused variable 'exePath' [-Werror,-Wunused-variabl
ClassFile API use an alternate labels inflation method for class versions < 50
(where StackMapTable attribute is optional).
The alternate method missed label inflation of lookup switch and table switch
instructions.
This patch fixes the label inflation method for for class versions < 50 and
adds
On Mon, 2 Sep 2024 09:05:17 GMT, Alan Bateman wrote:
>> David Holmes has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Exclude test on 32-bit
>
> Deprecating the existing function and introducing the new function looks okay.
>
> The test
On Mon, 2 Sep 2024 08:56:47 GMT, Per Minborg 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
On Mon, 2 Sep 2024 08:53:57 GMT, Per Minborg wrote:
> Here is the performance improvement for Linux a64. Looks like a significant
> improvement.
This looks good. Again, the goal of this PR is not to squeeze every nanosecond
out - but, rather, to achieve a performance model that is "sensible" -
On Fri, 30 Aug 2024 22:04:39 GMT, Francesco Nigro wrote:
> All of these strategies are better than what we have now, probably because
> the existing instrinsics still perform some poor decision, but I haven't dug
> yet into perfasm out to see what it does wrong; maybe is something which
> coul
On Wed, 21 Aug 2024 21:53:39 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 once,
On Fri, 30 Aug 2024 21:39:47 GMT, Brian Burkhalter wrote:
>> 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
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 Fri, 30 Aug 2024 14:15:24 GMT, Maurizio Cimadamore
wrote:
>> src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java
>> line 208:
>>
>>> 206: }
>>> 207: final long u = Byte.toUnsignedLong(value);
>>> 208: final long longValue = u <
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
Hi Anthony,
Thank you for your patience, I needed some time to experiment and think about
your feedback.
>* how realistic is it for type inference to be improved to the point that
>usage of the Gatherers API wouldn't require type arguments? Both technically
>and in terms of cost-benefit?
If l
65 matches
Mail list logo
