On Tue, 19 Dec 2023 21:17:02 GMT, Valeh Hajiyev wrote:
>> This commit addresses the current limitation in the `PriorityQueue`
>> implementation, which lacks a constructor to efficiently create a priority
>> queue with a custom comparator and an existing collection. In order to
>> create such
On Tue, 19 Dec 2023 21:14:40 GMT, Valeh Hajiyev wrote:
>> You should update the GitHub PR title to `6356745: (coll) Add
>> PriorityQueue(Collection, Comparator)` to match the JBS issue title.
>>
>> In addition, you will need a [CSR](https://wiki.openjdk.org/display/csr) as
>> the bot tells
On Mon, 18 Dec 2023 17:09:59 GMT, Serguei Spitsyn wrote:
>> This fix is for JDK 23 but the intention is to back port it to 22 in RDP-1
>> time frame.
>> It is fixing a deadlock issue between `VirtualThread` class critical
>> sections with the `interruptLock` (in methods: `unpark()`,
On Mon, 11 Dec 2023 02:36:30 GMT, Guoxiong Li wrote:
> Hi all,
>
> This patch fixes the building failure introduced by
> [JDK-8319577](https://bugs.openjdk.org/browse/JDK-8319577) in old GCC version
> (linux & GCC 7.5.0 locally).
>
> Thanks for the review.
>
> Best Regards,
> -- Guoxiong
On Tue, 19 Dec 2023 23:23:28 GMT, Kim Barrett wrote:
>>> @lgxbslgx We would like to keep GCC 8.4.0 as the minimum.
>>
>> Why? That's likely going to be in conflict with
>> https://github.com/openjdk/jdk/pull/14988.
>
>> @kimbarrett I meant to say that since the libsimdsort works with GCC
On Tue, 10 Oct 2023 02:54:05 GMT, Shaojin Wen wrote:
> By extracting the code that creates the exception, the CodeSize of these
> methods is less than the default FreqInlineSize 325. and for the scenario
> where the most commonly used radix is not specified and the String coder is
> LATIN1,
On Tue, 19 Dec 2023 21:34:02 GMT, Weibing Xiao wrote:
>> Better Error Handling for Jar Tool Processing of "@File"
>>
>> This is a new PR for this PR since the original developer left the team. See
>> all of the review history at https://github.com/openjdk/jdk/pull/16423.
>>
>> Thank you.
>
>
On Sat, 16 Dec 2023 14:07:52 GMT, Markus KARG wrote:
>> Fixes JDK-8322141
>>
>> As suggested by @vlsi and documented by @bplb this PR does not return, but
>> only sets the maximum result value.
>
> Markus KARG has updated the pull request incrementally with one additional
> commit since the
On Sun, 17 Dec 2023 13:25:00 GMT, Guoxiong Li wrote:
>> Hi all,
>>
>> This patch fixes the building failure introduced by
>> [JDK-8319577](https://bugs.openjdk.org/browse/JDK-8319577) in old GCC
>> version (linux & GCC 7.5.0 locally).
>>
>> Thanks for the review.
>>
>> Best Regards,
>> --
On Sun, 17 Dec 2023 13:25:00 GMT, Guoxiong Li wrote:
>> Hi all,
>>
>> This patch fixes the building failure introduced by
>> [JDK-8319577](https://bugs.openjdk.org/browse/JDK-8319577) in old GCC
>> version (linux & GCC 7.5.0 locally).
>>
>> Thanks for the review.
>>
>> Best Regards,
>> --
On Tue, 19 Dec 2023 19:08:08 GMT, Kim Barrett wrote:
>>> Have you tested with gcc 9? Or is this just supposition based on gcc9
>>> having removed the experimental
>> status for C++17?
>>
>> I have not tested GCC 8 and 9. @sviswa7 seems to test them.
>>
>>> I have verified that with the above
On Mon, 18 Dec 2023 11:56:50 GMT, Aleksei Voitylov
wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [fde5b168](https://github.com/openjdk/jdk/commit/fde5b16817c3263236993f2e8c2d2469610d99bd)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>
> The
On Tue, 19 Dec 2023 17:24:15 GMT, Weibing Xiao wrote:
>> Better Error Handling for Jar Tool Processing of "@File"
>>
>> This is a new PR for this PR since the original developer left the team. See
>> all of the review history at https://github.com/openjdk/jdk/pull/16423.
>>
>> Thank you.
>
>
On Mon, 18 Dec 2023 11:56:50 GMT, Aleksei Voitylov
wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [fde5b168](https://github.com/openjdk/jdk/commit/fde5b16817c3263236993f2e8c2d2469610d99bd)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>
> The
> Better Error Handling for Jar Tool Processing of "@File"
>
> This is a new PR for this PR since the original developer left the team. See
> all of the review history at https://github.com/openjdk/jdk/pull/16423.
>
> Thank you.
Weibing Xiao has updated the pull request incrementally with one
On Sun, 17 Dec 2023 15:20:50 GMT, Chen Liang wrote:
>> Valeh Hajiyev has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> updated the javadoc
>
> You should update the GitHub PR title to `6356745: (coll) Add
> PriorityQueue(Collection,
> This commit addresses the current limitation in the `PriorityQueue`
> implementation, which lacks a constructor to efficiently create a priority
> queue with a custom comparator and an existing collection. In order to create
> such a queue, we currently need to initialize a new queue with
On Sun, 17 Dec 2023 09:42:57 GMT, Alan Bateman wrote:
>> Valeh Hajiyev has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> updated the javadoc
>
> src/java.base/share/classes/java/util/PriorityQueue.java line 215:
>
>> 213: * Creates
> This commit addresses the current limitation in the `PriorityQueue`
> implementation, which lacks a constructor to efficiently create a priority
> queue with a custom comparator and an existing collection. In order to create
> such a queue, we currently need to initialize a new queue with
On Fri, 15 Dec 2023 12:54:27 GMT, Adam Sotona wrote:
> java.base java.lang.reflect.ProxyGenerator uses ASM to generate proxy classes.
>
> This patch converts it to use Classfile API.
>
> It is continuation of https://github.com/openjdk/jdk/pull/10991
>
> Any comments and suggestions are
On Tue, 19 Dec 2023 11:01:12 GMT, Hannes Greule wrote:
> Isn't Arrays.equals() used under the hood?
No, for arrays == is used
-
PR Comment: https://git.openjdk.org/jdk/pull/17143#issuecomment-1863374656
On Tue, 19 Dec 2023 12:21:05 GMT, Raffaello Giulietti
wrote:
>> Adds serialization misdeclaration events to JFR.
>
> Raffaello Giulietti has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Better name for a label, corrected name of removed
On Tue, 19 Dec 2023 17:41:57 GMT, Raffaello Giulietti
wrote:
>> Users (not OpenJDK developers) don't know what the error code means. I think
>> it's better to not have them. This is how other events work. If you want to
>> guard against changes, I would export the package to the test.
>
>
On Tue, 19 Dec 2023 19:08:08 GMT, Kim Barrett wrote:
>>> Have you tested with gcc 9? Or is this just supposition based on gcc9
>>> having removed the experimental
>> status for C++17?
>>
>> I have not tested GCC 8 and 9. @sviswa7 seems to test them.
>>
>>> I have verified that with the above
On Mon, 11 Dec 2023 16:37:38 GMT, Severin Gehwolf wrote:
>> Please review this patch which adds a jlink mode to the JDK which doesn't
>> need the packaged modules being present. A.k.a run-time image based jlink.
>> Fundamentally this patch adds an option to use `jlink` even though your JDK
>>
On Tue, 19 Dec 2023 02:22:05 GMT, Guoxiong Li wrote:
>> Guoxiong Li 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 four additional
>> commits
On Fri, 15 Dec 2023 10:02:56 GMT, Severin Gehwolf wrote:
>> Severin Gehwolf has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Disallow packaged modules and run-time image link
>> - Only check for existing path when not a scratch task
> Re-write the IndexOf code without the use of the pcmpestri instruction, only
> using AVX2 instructions. This change accelerates String.IndexOf on average
> 1.3x for AVX2. The benchmark numbers:
>
>
> BenchmarkScore
> Latest
On Sat, 16 Dec 2023 14:07:52 GMT, Markus KARG wrote:
>> Fixes JDK-8322141
>>
>> As suggested by @vlsi and documented by @bplb this PR does not return, but
>> only sets the maximum result value.
>
> Markus KARG has updated the pull request incrementally with one additional
> commit since the
On Sat, 16 Dec 2023 14:07:52 GMT, Markus KARG wrote:
>> Fixes JDK-8322141
>>
>> As suggested by @vlsi and documented by @bplb this PR does not return, but
>> only sets the maximum result value.
>
> Markus KARG has updated the pull request incrementally with one additional
> commit since the
On Tue, 19 Dec 2023 10:14:44 GMT, Sergey Tsypanov wrote:
> Shouldn't we keep at least the method for the classes checked in
> `BIS.isTrusted()`
You can keep it there or inline it. As Alan noted, the main thing is not to add
something like a new package.
-
PR Review Comment:
On Tue, 19 Dec 2023 17:37:50 GMT, Raffaello Giulietti
wrote:
>> src/java.base/share/classes/java/io/SerializationMisdeclarationChecker.java
>> line 39:
>>
>>> 37: import static java.lang.reflect.Modifier.*;
>>> 38:
>>> 39: final class SerializationMisdeclarationChecker {
>>
>> Is there a
On Tue, 19 Dec 2023 16:45:04 GMT, Raffaello Giulietti
wrote:
>> Adds serialization misdeclaration events to JFR.
>
> Raffaello Giulietti has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Changes according to reviewer's comments.
> You
On Tue, 19 Dec 2023 17:15:40 GMT, Erik Gahlin wrote:
>> Raffaello Giulietti has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Changes according to reviewer's comments.
>
>
On Tue, 19 Dec 2023 16:45:04 GMT, Raffaello Giulietti
wrote:
>> Adds serialization misdeclaration events to JFR.
>
> Raffaello Giulietti has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Changes according to reviewer's comments.
You mean,
On Tue, 19 Dec 2023 17:13:58 GMT, Erik Gahlin wrote:
>> The intent is that they are stable and for programmatic usage, whereas the
>> message is more for human consumption. The codes are used in the test, for
>> example, and are declared as public static in the event classes.
>>
>>
On Tue, 19 Dec 2023 16:28:03 GMT, Raffaello Giulietti
wrote:
> However, the cache can be emptied under high memory pressure, so the
> `ObjectStreamClass` instance might be recreated later, thus re-invoking the
> serialization checker once again.
I think it would be good to state in the
On Tue, 19 Dec 2023 12:47:53 GMT, Goetz Lindenmaier wrote:
> …g exception
>
> After leaving the method by throwing an exception the data can not be cleaned
> any more.
LGTM. Please remove the redundant package name before push.
src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java
On Thu, 7 Dec 2023 06:28:43 GMT, Serguei Spitsyn wrote:
> This fix is for JDK 23 but the intention is to back port it to 22 in RDP-1
> time frame.
> It is fixing a deadlock issue between `VirtualThread` class critical sections
> with the `interruptLock` (in methods: `unpark()`, `interrupt()`,
On Tue, 19 Dec 2023 16:00:59 GMT, Raffaello Giulietti
wrote:
>> test/jdk/jdk/jfr/event/io/TestSerializationMisdeclarationEvent.java line 50:
>>
>>> 48: * @requires vm.hasJFR
>>> 49: * @library /test/lib
>>> 50: * @run junit/othervm
>>> jdk.jfr.event.io.TestSerializationMisdeclarationEvent
On Tue, 19 Dec 2023 12:47:53 GMT, Goetz Lindenmaier wrote:
> …g exception
>
> After leaving the method by throwing an exception the data can not be cleaned
> any more.
Seems reasonable.
-
Marked as reviewed by stuefe (Reviewer).
PR Review:
> Better Error Handling for Jar Tool Processing of "@File"
>
> This is a new PR for this PR since the original developer left the team. See
> all of the review history at https://github.com/openjdk/jdk/pull/16423.
>
> Thank you.
Weibing Xiao has updated the pull request incrementally with one
On Tue, 19 Dec 2023 16:45:04 GMT, Raffaello Giulietti
wrote:
>> Adds serialization misdeclaration events to JFR.
>
> Raffaello Giulietti has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Changes according to reviewer's comments.
On Tue, 19 Dec 2023 12:17:38 GMT, Raffaello Giulietti
wrote:
>> src/jdk.jfr/share/classes/jdk/jfr/events/SerializationMisdeclarationEvent.java
>> line 48:
>>
>>> 46:
>>> 47: @Label("Kind")
>>> 48: public int kind;
>>
>> What is the use case for error codes? Are they public or an
On Mon, 11 Dec 2023 05:47:33 GMT, Justin Lu wrote:
>> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8319982)
>> which overrides and provides an implementation of `toString()` in
>> _java.util.zip.ZipFile_ (and by extension, _java.util.jar.JarFile_).
>
> Justin Lu has
On Tue, 19 Dec 2023 02:22:05 GMT, Guoxiong Li wrote:
>> Guoxiong Li 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 four additional
>> commits
> Adds serialization misdeclaration events to JFR.
Raffaello Giulietti has updated the pull request incrementally with one
additional commit since the last revision:
Changes according to reviewer's comments.
-
Changes:
- all: https://git.openjdk.org/jdk/pull/17129/files
-
On Mon, 18 Dec 2023 11:56:50 GMT, Aleksei Voitylov
wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [fde5b168](https://github.com/openjdk/jdk/commit/fde5b16817c3263236993f2e8c2d2469610d99bd)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>
> The
On Tue, 19 Dec 2023 15:56:39 GMT, Raffaello Giulietti
wrote:
> > Is it per class for each classloader that loads it? Or is it per class per
> > JVM? It's more out of curiosity than anything else because I don't think it
> > makes a big difference (I don't expect too many classloaders that
On Tue, 19 Dec 2023 14:39:47 GMT, Jaikiran Pai wrote:
> Is it per class for each classloader that loads it? Or is it per class per
> JVM? It's more out of curiosity than anything else because I don't think it
> makes a big difference (I don't expect too many classloaders that would lead
> to
On Tue, 19 Dec 2023 08:11:42 GMT, Bernd wrote:
> > If what you're saying is "Previously we were implicitly verifying that the
> > data reported by `available()` was actually there, and now we're no longer
> > verifying that" then that's not correct.
>
> I mean it verified the non-zero
On Tue, 19 Dec 2023 12:21:05 GMT, Raffaello Giulietti
wrote:
>> Adds serialization misdeclaration events to JFR.
>
> Raffaello Giulietti has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Better name for a label, corrected name of removed
On Tue, 19 Dec 2023 12:21:05 GMT, Raffaello Giulietti
wrote:
>> Adds serialization misdeclaration events to JFR.
>
> Raffaello Giulietti has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Better name for a label, corrected name of removed
> Currently if we create a record it's fields are compared in their declaration
> order. This might be ineffective in cases when two objects have "heavy"
> fields equals to each other, but different "lightweight" fields (heavy and
> lightweight in terms of comparison) e.g. primitives, enums,
>
On Tue, 19 Dec 2023 12:21:05 GMT, Raffaello Giulietti
wrote:
>> Adds serialization misdeclaration events to JFR.
>
> Raffaello Giulietti has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Better name for a label, corrected name of removed
On Tue, 19 Dec 2023 12:21:05 GMT, Raffaello Giulietti
wrote:
>> Adds serialization misdeclaration events to JFR.
>
> Raffaello Giulietti has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Better name for a label, corrected name of removed
On Tue, 19 Dec 2023 12:21:05 GMT, Raffaello Giulietti
wrote:
>> Adds serialization misdeclaration events to JFR.
>
> Raffaello Giulietti has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Better name for a label, corrected name of removed
On Tue, 19 Dec 2023 12:21:05 GMT, Raffaello Giulietti
wrote:
>> Adds serialization misdeclaration events to JFR.
>
> Raffaello Giulietti has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Better name for a label, corrected name of removed
On Tue, 19 Dec 2023 12:21:05 GMT, Raffaello Giulietti
wrote:
>> Adds serialization misdeclaration events to JFR.
>
> Raffaello Giulietti has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Better name for a label, corrected name of removed
On Mon, 18 Dec 2023 11:56:50 GMT, Aleksei Voitylov
wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [fde5b168](https://github.com/openjdk/jdk/commit/fde5b16817c3263236993f2e8c2d2469610d99bd)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>
> The
On Tue, 19 Dec 2023 12:47:53 GMT, Goetz Lindenmaier wrote:
> …g exception
>
> After leaving the method by throwing an exception the data can not be cleaned
> any more.
Marked as reviewed by mbaesken (Reviewer).
-
PR Review:
On Tue, 19 Dec 2023 12:21:05 GMT, Raffaello Giulietti
wrote:
>> Adds serialization misdeclaration events to JFR.
>
> Raffaello Giulietti has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Better name for a label, corrected name of removed
On Wed, 13 Dec 2023 18:16:56 GMT, Weibing Xiao wrote:
> Better Error Handling for Jar Tool Processing of "@File"
>
> This is a new PR for this PR since the original developer left the team. See
> all of the review history at https://github.com/openjdk/jdk/pull/16423.
>
> Thank you.
Hello
…g exception
After leaving the method by throwing an exception the data can not be cleaned
any more.
-
Commit messages:
- 8320798: Console read line with zero out should zero out when throwing
exception
Changes: https://git.openjdk.org/jdk/pull/17156/files
Webrev:
> Adds serialization misdeclaration events to JFR.
Raffaello Giulietti has updated the pull request incrementally with one
additional commit since the last revision:
Better name for a label, corrected name of removed field.
-
Changes:
- all:
On Tue, 19 Dec 2023 10:43:57 GMT, Erik Gahlin wrote:
>> Raffaello Giulietti has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Event enabled on profile.jfc but disabled on default.jfc.
>
>
On Tue, 19 Dec 2023 09:41:45 GMT, Sergey Tsypanov wrote:
> Isn't `Arrays.equals()` used under the hood?
The JLS and the API spec don't mention any special-casing of arrays, and the
code seems to use `Objects.equals` for all non-primitive types:
On Mon, 18 Dec 2023 17:49:04 GMT, Raffaello Giulietti
wrote:
>> Adds serialization misdeclaration events to JFR.
>
> Raffaello Giulietti has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Event enabled on profile.jfc but disabled on
On Sat, 16 Dec 2023 17:51:30 GMT, Markus KARG wrote:
>> Sergey Tsypanov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8320971: Revert irrelevant changes
>
> test/jdk/java/io/BufferedInputStream/TransferToTrusted.java line 85:
>
>>
> It looks like we can skip copying of `byte[]` in
> `BufferedInputStream.implTransferTo()` for `OutputStreams` residing in
> `java.io`.
>
> See comment by @vlsi in
> https://github.com/openjdk/jdk/pull/10525/files#diff-e19c508d1bb6ee78697ecca66947c395adda0d9c49a85bf696e677ecbd977af1R612
> Currently if we create a record it's fields are compared in their declaration
> order. This might be ineffective in cases when two objects have "heavy"
> fields equals to each other, but different "lightweight" fields (heavy and
> lightweight in terms of comparison) e.g. primitives, enums,
>
On Tue, 19 Dec 2023 06:07:31 GMT, Hannes Greule wrote:
> Arrays are compared by reference
Isn't `Arrays.equals()` used under the hood?
> You are sorting the array passed to the bootstrap method
Good point, fixed.
-
PR Comment:
Hello Chen,
Looking at the implementation of java.lang.Class.getName(), which then
triggers the hotspot code to initialize this "name" field, I suspect
there will be a (harmless) race in the hotspot implementation where more
than one thread could end up writing the "name" field (with the same
On Mon, 18 Dec 2023 20:37:29 GMT, Chris Plummer wrote:
> I'm working on a test where I just added a CountDownLatch(1) and am wondering
> if I should do the same, but I'm not sure if there is something about these
> tests that is motivating the change.
CountDownLatch is great for many tests.
On Sat, 16 Dec 2023 17:48:39 GMT, Archie Cobbs wrote:
> If what you're saying is "Previously we were implicitly verifying that the
> data reported by `available()` was actually there, and now we're no longer
> verifying that" then that's not correct.
I mean it verified the non-zero behavior,
75 matches
Mail list logo
