On Sat, 14 Jan 2023 14:28:32 GMT, Jie Fu wrote:
> It occurred while building LIBJLI, LIBZIP and LIBSPLASHSCREEN.
Is there a list of the issues building libjli? I don't see the in the PR or the
JBS issue. For the libzip issues, are these in the native methods or when
compiling the zlib code, ju
On Mon, 16 Jan 2023 08:21:47 GMT, Alan Bateman wrote:
> Is there a list of the issues building libjli? I don't see the in the PR or
> the JBS issue. For the libzip issues, are these in the native methods or when
> compiling the zlib code, just wondering if there are bug reports for upstream
>
On Mon, 16 Jan 2023 08:51:34 GMT, Jie Fu wrote:
> For the libzip issues, are these in the native methods or when compiling the
> zlib code, just wondering if there are bug reports for upstream there too.
Mainly caused by files under `src/java.base/share/native/libzip/zlib/`.
I'm not sure if the
On Mon, 16 Jan 2023 08:56:13 GMT, Jie Fu wrote:
> Mainly caused by files under `src/java.base/share/native/libzip/zlib/`. I'm
> not sure if there is already a bug report to the upstream.
Maybe this one:
https://github.com/madler/zlib/issues/633
-
PR: https://git.openjdk.org/jdk/pu
On Fri, 13 Jan 2023 22:48:59 GMT, Archie L. Cobbs wrote:
>> This PR adds a new lint warning category `this-escape`.
>>
>> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to
>> allow the JDK to continue to compile with `-Xlint:all`.
>>
>> A 'this' escape warning is gene
> Some call sites of SignatureFileVerifier.isBlockOrSF fails to check that
> files reside in META-INF directly, and not in a subdirectory of META-INF.
>
> The mentioned call sites needs updates to check and ignore such files.
>
> A new test VerifyUnrelatedSignatureFiles is added which verifies t
On Fri, 13 Jan 2023 21:28:51 GMT, Archie L. Cobbs wrote:
>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java
>> line 1088:
>>
>>> 1086: private void visitLooped(T tree, Consumer
>>> visitor) {
>>> 1087: visitScoped(tree, false, t -> {
>>> 1088:
On Mon, 9 Jan 2023 03:34:55 GMT, Glavo wrote:
> `JavaLangAccess::newStringUTF8NoRepl` and
> `JavaLangAccess::getBytesUTF8NoRepl` are not implemented correctly. They
> always copy arrays, rather than avoiding copying as much as possible as
> javadoc says.
>
> I ran the tier1 test without any n
On Fri, 13 Jan 2023 22:54:47 GMT, Joe Darcy wrote:
>> With generalized see and link tags that can refer to anchors (JDK-8200337),
>> the see and link tags in core libraries should be updated to use this
>> feature when possible. This PR covers such updates for java.base.
>
> Joe Darcy has updat
On Mon, 16 Jan 2023 11:53:40 GMT, Maurizio Cimadamore
wrote:
>> Archie L. Cobbs has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Fix bug where field initializer warnings could be incorrectly suppressed.
>> - Consolidate all the unit t
On Mon, 16 Jan 2023 12:51:49 GMT, Maurizio Cimadamore
wrote:
>> The number of times around any single loop is bounded by the number of new
>> references that can possibly be created during the analysis of that loop.
>>
>> That number is at most 2 * (1 + 1 + 1 + 1 + N) where N is the number of
> [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729) was created in an
> attempt to remove all trailing whitespace from properties files, and enable a
> jcheck verification that they did not come back, similar to other source
> code. It turned out that this was not so simple, however, si
On Fri, 2 Dec 2022 17:06:23 GMT, Magnus Ihse Bursie wrote:
> [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729) was created in an
> attempt to remove all trailing whitespace from properties files, and enable a
> jcheck verification that they did not come back, similar to other source
>
On Mon, 16 Jan 2023 16:29:31 GMT, Archie L. Cobbs wrote:
> It looks like you might be counting the "here via invocation" lines as
> separate warnings. These are really part of the previous `possible 'this'
> escape` line, e.g.:
yes, I really did the simplest possible thing (e.g. just counting
On Thu, 12 Jan 2023 15:31:03 GMT, Raffaello Giulietti
wrote:
>> This change transforms a O(n^2) path to O(n) when prepending zero padding to
>> decimal outputs, where n is the length of the padding.
>
> Raffaello Giulietti has updated the pull request incrementally with one
> additional commit
On Thu, 12 Jan 2023 11:40:32 GMT, Sergey Tsypanov wrote:
>> Raffaello Giulietti has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8299677: Formatter.format might take a long time to format an integer or
>> floating-point
>
> src/java.base
On Mon, 16 Jan 2023 16:50:06 GMT, Magnus Ihse Bursie wrote:
>> [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729) was created in an
>> attempt to remove all trailing whitespace from properties files, and enable
>> a jcheck verification that they did not come back, similar to other sourc
On Fri, 13 Jan 2023 22:54:47 GMT, Joe Darcy wrote:
>> With generalized see and link tags that can refer to anchors (JDK-8200337),
>> the see and link tags in core libraries should be updated to use this
>> feature when possible. This PR covers such updates for java.base.
>
> Joe Darcy has updat
On Mon, 16 Jan 2023 15:06:25 GMT, Daniel Fuchs wrote:
>> Joe Darcy has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix typo found in code review.
>
> src/java.base/share/classes/java/lang/CharSequence.java line 76:
>
>> 74: *
>> 75
On Mon, 16 Jan 2023 17:13:52 GMT, balcanuc wrote:
>> Raffaello Giulietti has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8299677: Formatter.format might take a long time to format an integer or
>> floating-point
>
> in which JDK version
On Mon, 16 Jan 2023 17:22:36 GMT, Roger Riggs wrote:
>> Magnus Ihse Bursie has updated the pull request with a new target base due
>> to a merge or a rebase. The pull request now contains two commits:
>>
>> - Merge branch 'master' into properties-eol-clean-safe
>> - 8298047: Remove all non-si
On Fri, 2 Dec 2022 17:06:23 GMT, Magnus Ihse Bursie wrote:
> [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729) was created in an
> attempt to remove all trailing whitespace from properties files, and enable a
> jcheck verification that they did not come back, similar to other source
>
> Continuing the work initiated by @luhenry to unroll and then intrinsify
> polynomial hash loops.
>
> I've rewired the library changes to route via a single `@IntrinsicCandidate`
> method. To make this work I've harmonized how they are invoked so that
> there's less special handling and checks
> This PR adds a new lint warning category `this-escape`.
>
> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to
> allow the JDK to continue to compile with `-Xlint:all`.
>
> A 'this' escape warning is generated for a constructor `A()` in a class `A`
> when the compiler
> Continuing the work initiated by @luhenry to unroll and then intrinsify
> polynomial hash loops.
>
> I've rewired the library changes to route via a single `@IntrinsicCandidate`
> method. To make this work I've harmonized how they are invoked so that
> there's less special handling and checks
On Mon, 14 Nov 2022 18:28:53 GMT, Vladimir Ivanov wrote:
>>> Also, I'd like to note that C2 auto-vectorization support is not too far
>>> away from being able to optimize hash code computations. At some point, I
>>> was able to achieve some promising results with modest tweaking of
>>> SuperWo
On Wed, 4 Jan 2023 13:16:26 GMT, Andriy Plokhotnyuk wrote:
>
> Do you see any concrete examples of classes in the JDK that could benefit
> from a "VarHandlization"?
`ImageOutputStreamImpl` and `ImageInputStreamImpl` in `javax.imageio.stream`
have some very similar code that might benefit.
On Fri, 13 Jan 2023 11:30:35 GMT, Jorn Vernee wrote:
> Excellent. No Comments.
>
> I am running some sanity testing on our CI, and will approve when it comes
> back green.
@JornVernee, thanks for the reviewing and testing!
-
PR: https://git.openjdk.org/jdk/pull/11004
On Sat, 14 Jan 2023 14:28:32 GMT, Jie Fu wrote:
> Hi all,
>
> Please review the fix for the build failure with clang-15.
>
> 1. -Wbitwise-instead-of-logical
>
>1) src/hotspot/share/oops/generateOopMap.cpp <--- fixed the
> warning
>2) src/hotspot/share/runtime/notificationThre
On Mon, 9 Jan 2023 09:22:25 GMT, Per Minborg wrote:
>> Currently, `java.io.Bits` is using explicit logic to read/write various
>> primitive types to/from byte arrays. Switching to the use of `VarHandle`
>> access would provide better performance and less code.
>>
>> Also, using a standard API
On Tue, 17 Jan 2023 04:29:31 GMT, David Holmes wrote:
> Hotspot changes are good.
Thanks @dholmes-ora .
-
PR: https://git.openjdk.org/jdk/pull/12005
On Mon, 9 Jan 2023 03:34:55 GMT, Glavo wrote:
> `JavaLangAccess::newStringUTF8NoRepl` and
> `JavaLangAccess::getBytesUTF8NoRepl` are not implemented correctly. They
> always copy arrays, rather than avoiding copying as much as possible as
> javadoc says.
>
> I ran the tier1 test without any n
On Tue, 17 Jan 2023 01:08:09 GMT, j3graham wrote:
> > Do you see any concrete examples of classes in the JDK that could benefit
> > from a "VarHandlization"?
>
> `ImageOutputStreamImpl` and `ImageInputStreamImpl` in `javax.imageio.stream`
> have some very similar code that might benefit. Also
On Wed, 4 Jan 2023 08:48:56 GMT, Per Minborg wrote:
> Currently, `java.io.Bits` is using explicit logic to read/write various
> primitive types to/from byte arrays. Switching to the use of `VarHandle`
> access would provide better performance and less code.
>
> Also, using a standard API for
34 matches
Mail list logo
