On Wed, 15 May 2024 03:28:29 GMT, SendaoYan wrote:
> Hi all,
> The `tools/jlink/JLinkReproducibleTest.java` intermittent fails on linux
> aarch64. Should we mark this testcase as `@key intermittent`. No risk.
>
> Thanks.
> -sendao
This pull request has been closed without being integrated.
On Wed, 15 May 2024 03:41:02 GMT, Jaikiran Pai wrote:
> Hello @sendaoYan, the linked issue
> https://bugs.openjdk.org/browse/JDK-8327181 which talks about a JVM crash
> looks very generic and not specific to this test. Before updating this test,
> I think that issue needs to investigated and
On Wed, 15 May 2024 03:28:29 GMT, SendaoYan wrote:
> Hi all,
> The `tools/jlink/JLinkReproducibleTest.java` intermittent fails on linux
> aarch64. Should we mark this testcase as `@key intermittent`. No risk.
>
> Thanks.
> -sendao
Hello @sendaoYan, the linked issue
Hi all,
The `tools/jlink/JLinkReproducibleTest.java` intermittent fails on linux
aarch64. Should we mark this testcase as `@key intermittent`. No risk.
Thanks.
-sendao
-
Commit messages:
- 8332260: mark tools/jlink/JLinkReproducibleTest.java as intermittent failure
- 8332260:
On Mon, 13 May 2024 15:32:27 GMT, Alan Bateman wrote:
>> Maurizio Cimadamore has updated the pull request incrementally with three
>> additional commits since the last revision:
>>
>> - Fix another typo
>> - Fix typo
>> - Add more comments
>
> src/hotspot/share/runtime/arguments.cpp line
On Tue, 14 May 2024 18:10:28 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and
On Tue, 14 May 2024 14:31:52 GMT, Pavel Rappo wrote:
>> src/java.base/share/classes/java/io/IO.java line 98:
>>
>>> 96: * or if an I/O error occurs
>>> 97: */
>>> 98: public static String readln(String prompt) {
>>
>> Did we consider Optional here? Maybe that is
On Sat, 4 May 2024 19:35:21 GMT, Scott Gibbons wrote:
>> 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:
>>
>>
>> Benchmark
On Mon, 13 May 2024 09:56:35 GMT, Pavel Rappo wrote:
>> Please review this PR which introduces the `java.io.IO` top-level class and
>> three methods to `java.io.Console` for [Implicitly Declared Classes and
>> Instance Main Methods (Third Preview)].
>>
>> This PR has been obtained as `git
> Making sure `restoreEcho` correctly reflects the state in the shutdown
> thread, which differs from the application's thread that issues the
> `readPassword()` method.
Naoto Sato has updated the pull request incrementally with one additional
commit since the last revision:
copyright year
On Tue, 14 May 2024 21:30:16 GMT, Naoto Sato wrote:
>> Making sure `restoreEcho` correctly reflects the state in the shutdown
>> thread, which differs from the application's thread that issues the
>> `readPassword()` method.
>
> Naoto Sato has updated the pull request with a new target base
On Tue, 7 May 2024 11:53:19 GMT, Pavel Rappo wrote:
> Please review this mechanical change to man pages. This PR should be
> integrated after https://github.com/openjdk/jdk/pull/18787.
This pull request has been closed without being integrated.
-
PR:
On Tue, 7 May 2024 11:53:19 GMT, Pavel Rappo wrote:
> Please review this mechanical change to man pages. This PR should be
> integrated after https://github.com/openjdk/jdk/pull/18787.
Withdrawing this, as a different approach is required.
-
PR Comment:
> Making sure `restoreEcho` correctly reflects the state in the shutdown
> thread, which differs from the application's thread that issues the
> `readPassword()` method.
Naoto Sato has updated the pull request with a new target base due to a merge
or a rebase. The incremental webrev excludes
On Tue, 14 May 2024 17:25:37 GMT, Claes Redestad wrote:
>> This PR suggests refactoring the implementation classes of
>> java.lang.constant into a new package jdk.internal.constant to enable
>> sharing some trusted static factory methods with users elsewhere in
>> java.base, such as
On Mon, 13 May 2024 21:32:18 GMT, Naoto Sato wrote:
>> Making sure `restoreEcho` correctly reflects the state in the shutdown
>> thread, which differs from the application's thread that issues the
>> `readPassword()` method.
>
> Naoto Sato has updated the pull request incrementally with one
On Mon, 13 May 2024 21:32:18 GMT, Naoto Sato wrote:
>> Making sure `restoreEcho` correctly reflects the state in the shutdown
>> thread, which differs from the application's thread that issues the
>> `readPassword()` method.
>
> Naoto Sato has updated the pull request incrementally with one
> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
> the use of JNI in the following ways:
>
> * `System::load` and `System::loadLibrary` are now restricted methods
> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
> * binding a JNI `native`
On Mon, 13 May 2024 21:32:18 GMT, Naoto Sato wrote:
>> Making sure `restoreEcho` correctly reflects the state in the shutdown
>> thread, which differs from the application's thread that issues the
>> `readPassword()` method.
>
> Naoto Sato has updated the pull request incrementally with one
On Tue, 14 May 2024 17:25:37 GMT, Claes Redestad wrote:
>> This PR suggests refactoring the implementation classes of
>> java.lang.constant into a new package jdk.internal.constant to enable
>> sharing some trusted static factory methods with users elsewhere in
>> java.base, such as
> This PR suggests refactoring the implementation classes of java.lang.constant
> into a new package jdk.internal.constant to enable sharing some trusted
> static factory methods with users elsewhere in java.base, such as
> java.lang.invoke and java.lang.classfile. The refactoring also adds
On Sun, 12 May 2024 08:36:44 GMT, Chen Liang wrote:
> Some tests are not migrated to the ClassFile API in previous migrations.
>
> - Some are simple oversights that didn't remove usages of
> com.sun.tools.classfile;
> - The CallerSensitive ones used an old utility, replaced by CF API-based
> Proposing new overloaded methods in `java.io.Console` class that explicitly
> take a `Locale` argument. Existing methods rely on the default locale, so the
> users won't be able to format their prompts/outputs in a certain locale
> explicitly.
Naoto Sato has updated the pull request with a
On Mon, 13 May 2024 21:32:18 GMT, Naoto Sato wrote:
>> Making sure `restoreEcho` correctly reflects the state in the shutdown
>> thread, which differs from the application's thread that issues the
>> `readPassword()` method.
>
> Naoto Sato has updated the pull request incrementally with one
On Tue, 14 May 2024 14:51:20 GMT, Per Minborg wrote:
>> # Stable Values & Collections (Internal)
>>
>> ## Summary
>> This PR proposes to introduce an internal _Stable Values & Collections_ API,
>> which provides immutable value holders where elements are initialized _at
>> most once_. Stable
On Tue, 14 May 2024 15:40:24 GMT, ExE Boss wrote:
>> Raffaello Giulietti has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Move mathematical logic to record RandomGeneratorProperties.
>
>
> All random number generator algorithms are implemented in module `java.base`.
> The usage of `ServiceLoader` in `j.u.r.RandomGeneratorFactory` is no longer
> needed.
Raffaello Giulietti has updated the pull request incrementally with one
additional commit since the last revision:
Replace
On Tue, 14 May 2024 14:51:20 GMT, Per Minborg wrote:
>> # Stable Values & Collections (Internal)
>>
>> ## Summary
>> This PR proposes to introduce an internal _Stable Values & Collections_ API,
>> which provides immutable value holders where elements are initialized _at
>> most once_. Stable
On Tue, 14 May 2024 13:18:51 GMT, Adam Sotona wrote:
> Class file with `LineNumberTable` attribute element pointing behind the
> bytecode array throws `ArrayIndexOutOfBoundsException`.
> This patch performs the check and throws expected `IllegalArgumentException`
> instead.
> Relevant test is
On Tue, 14 May 2024 13:47:33 GMT, Raffaello Giulietti
wrote:
>> All random number generator algorithms are implemented in module
>> `java.base`. The usage of `ServiceLoader` in `j.u.r.RandomGeneratorFactory`
>> is no longer needed.
>
> Raffaello Giulietti has updated the pull request
(Moving to core-libs-dev)
On Tue, May 14, 2024 at 9:40 AM Alan Bateman
wrote:
> On 14/05/2024 14:42, David Lloyd wrote:
>
> ReflectionFactory allows access to serialization facilities without any
> access checking (other than the defunct SecurityManager checks). Perhaps
> this class could gain
On Tue, 14 May 2024 14:19:44 GMT, Alan Bateman wrote:
>> Per Minborg has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove text in public class that references an internal class
>
>
> # Stable Values & Collections (Internal)
>
> ## Summary
> This PR proposes to introduce an internal _Stable Values & Collections_ API,
> which provides immutable value holders where elements are initialized _at
> most once_. Stable Values & Collections offer the performance and safety
>
On Tue, 14 May 2024 14:27:35 GMT, Per Minborg wrote:
>> Pavel Rappo 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 17 additional
>> commits
On Mon, 13 May 2024 09:56:35 GMT, Pavel Rappo wrote:
>> Please review this PR which introduces the `java.io.IO` top-level class and
>> three methods to `java.io.Console` for [Implicitly Declared Classes and
>> Instance Main Methods (Third Preview)].
>>
>> This PR has been obtained as `git
On Tue, 16 Apr 2024 11:47:23 GMT, Per Minborg wrote:
> # Stable Values & Collections (Internal)
>
> ## Summary
> This PR proposes to introduce an internal _Stable Values & Collections_ API,
> which provides immutable value holders where elements are initialized _at
> most once_. Stable Values
On Mon, 22 Apr 2024 09:34:39 GMT, Per Minborg wrote:
>> src/java.base/share/classes/jdk/internal/lang/stable/StableValueElement.java
>> line 116:
>>
>>> 114: public V computeIfUnset(Supplier supplier) {
>>> 115: // Todo: This creates a lambda
>>> 116: return
On Fri, 19 Apr 2024 09:32:56 GMT, ExE Boss wrote:
>> # Stable Values & Collections (Internal)
>>
>> ## Summary
>> This PR proposes to introduce an internal _Stable Values & Collections_ API,
>> which provides immutable value holders where elements are initialized _at
>> most once_. Stable
On Wed, 17 Apr 2024 13:23:53 GMT, Maurizio Cimadamore
wrote:
>> I see what you mean. Initially, I thought it would be easy to create
>> memorized functions but it turned out, that was not the case if one wants to
>> retain easy debugability etc. So, I have added a couple of factory methods
On Wed, 17 Apr 2024 11:12:37 GMT, Per Minborg wrote:
>> Yes, consider the 3 capture scenarios:
>> | API | Capture frequency | Capture Impact | Code Convenience | Flexibility |
>> |-|---||--|-|
>> | `StableValue.ofMap(map, k -> ...)`
On Mon, 22 Apr 2024 17:09:39 GMT, Chen Liang wrote:
>> src/java.base/share/classes/jdk/internal/lang/StableValue.java line 130:
>>
>>> 128: * } else {
>>> 129: * V newValue = supplier.get();
>>> 130: * stable.setOrThrow(newValue);
>>
>> If ::computeIfUnset allows racy
On Mon, 22 Apr 2024 16:16:39 GMT, Dan Heidinga wrote:
>> # Stable Values & Collections (Internal)
>>
>> ## Summary
>> This PR proposes to introduce an internal _Stable Values & Collections_ API,
>> which provides immutable value holders where elements are initialized _at
>> most once_. Stable
On Wed, 17 Apr 2024 14:24:59 GMT, Maurizio Cimadamore
wrote:
>> # Stable Values & Collections (Internal)
>>
>> ## Summary
>> This PR proposes to introduce an internal _Stable Values & Collections_ API,
>> which provides immutable value holders where elements are initialized _at
>> most
On Tue, 23 Apr 2024 12:18:53 GMT, Per Minborg wrote:
>> Good idea.
>
> Ahh. I thought you meant pattern matching in another place (which actually
> turned out to be a really good idea). Here, however, we also need to get the
> type parameters correct:
>
>
On Tue, 16 Apr 2024 11:47:23 GMT, Per Minborg wrote:
> # Stable Values & Collections (Internal)
>
> ## Summary
> This PR proposes to introduce an internal _Stable Values & Collections_ API,
> which provides immutable value holders where elements are initialized _at
> most once_. Stable Values
On Tue, 23 Apr 2024 12:22:25 GMT, Per Minborg wrote:
>> src/java.base/share/classes/java/lang/reflect/AccessibleObject.java line 193:
>>
>>> 191: * final fields declared in a {@linkplain Class#isHidden()
>>> hidden class}
>>> 192: * final fields declared in a {@linkplain
On Mon, 13 May 2024 12:18:28 GMT, Chen Liang wrote:
>> As we need the array in both cases, how would such a solution look like
>> without duplicating code?
>
> I was thinking about changing the StableEnumMap factory to directly take an
> EnumSet/BitSet indicating the indices without
On Tue, 23 Apr 2024 09:17:29 GMT, Per Minborg wrote:
>> src/java.base/share/classes/java/util/ImmutableCollections.java line 183:
>>
>>> 181:K key,
>>> 182:Function>> extends V> mapper) {
>>> 183:
On Tue, 14 May 2024 11:07:00 GMT, Per Minborg wrote:
>> # Stable Values & Collections (Internal)
>>
>> ## Summary
>> This PR proposes to introduce an internal _Stable Values & Collections_ API,
>> which provides immutable value holders where elements are initialized _at
>> most once_. Stable
On Mon, 22 Apr 2024 16:31:15 GMT, Dan Heidinga wrote:
>> # Stable Values & Collections (Internal)
>>
>> ## Summary
>> This PR proposes to introduce an internal _Stable Values & Collections_ API,
>> which provides immutable value holders where elements are initialized _at
>> most once_. Stable
On Tue, 16 Apr 2024 11:47:23 GMT, Per Minborg wrote:
> # Stable Values & Collections (Internal)
>
> ## Summary
> This PR proposes to introduce an internal _Stable Values & Collections_ API,
> which provides immutable value holders where elements are initialized _at
> most once_. Stable Values
On Tue, 16 Apr 2024 11:47:23 GMT, Per Minborg wrote:
> # Stable Values & Collections (Internal)
>
> ## Summary
> This PR proposes to introduce an internal _Stable Values & Collections_ API,
> which provides immutable value holders where elements are initialized _at
> most once_. Stable Values
# Stable Values & Collections (Internal)
## Summary
This PR proposes to introduce an internal _Stable Values & Collections_ API,
which provides immutable value holders where elements are initialized _at most
once_. Stable Values & Collections offer the performance and safety benefits of
final
On Wed, 17 Apr 2024 15:17:52 GMT, Per Minborg wrote:
>> Also, I want to mention a few important differences between `@Stable` and
>> Stable Values:
>>
>> Patterns:
>> 1. Benign race (does not exist in StableValue API): multiple threads can
>> create an instance and upload, any non-null
On Wed, 17 Apr 2024 14:07:05 GMT, Chen Liang wrote:
> Question:
>
> 1. Will we ever try to expose the stable benign race model to users?
> 2. Will we ever try to inline the stable values in object layout like a
> stable field?
1. I think there is little or no upside in exposing the benign
On Tue, 16 Apr 2024 11:47:23 GMT, Per Minborg wrote:
> # Stable Values & Collections (Internal)
>
> ## Summary
> This PR proposes to introduce an internal _Stable Values & Collections_ API,
> which provides immutable value holders where elements are initialized _at
> most once_. Stable Values
On Wed, 17 Apr 2024 15:17:52 GMT, Per Minborg wrote:
>> Also, I want to mention a few important differences between `@Stable` and
>> Stable Values:
>>
>> Patterns:
>> 1. Benign race (does not exist in StableValue API): multiple threads can
>> create an instance and upload, any non-null
On Tue, 16 Apr 2024 11:47:23 GMT, Per Minborg wrote:
> # Stable Values & Collections (Internal)
>
> ## Summary
> This PR proposes to introduce an internal _Stable Values & Collections_ API,
> which provides immutable value holders where elements are initialized _at
> most once_. Stable Values
On Tue, 14 May 2024 13:32:39 GMT, Naoto Sato wrote:
> I thought of the same scenario that is certainly possible. Now I am tempted
> to avoid this race condition altogether by removing checking restoreEcho and
> always issue echo(true). What do you guys think?
It should be possible to provide
> All random number generator algorithms are implemented in module `java.base`.
> The usage of `ServiceLoader` in `j.u.r.RandomGeneratorFactory` is no longer
> needed.
Raffaello Giulietti has updated the pull request incrementally with one
additional commit since the last revision:
Move
On Mon, 13 May 2024 21:32:18 GMT, Naoto Sato wrote:
>> Making sure `restoreEcho` correctly reflects the state in the shutdown
>> thread, which differs from the application's thread that issues the
>> `readPassword()` method.
>
> Naoto Sato has updated the pull request incrementally with one
Class file with `LineNumberTable` attribute element pointing behind the
bytecode array throws `ArrayIndexOutOfBoundsException`.
This patch performs the check and throws expected `IllegalArgumentException`
instead.
Relevant test is added.
Please review.
Thanks,
Adam
-
Commit
> All random number generator algorithms are implemented in module `java.base`.
> The usage of `ServiceLoader` in `j.u.r.RandomGeneratorFactory` is no longer
> needed.
Raffaello Giulietti has updated the pull request incrementally with one
additional commit since the last revision:
Replaced
> This PR suggests refactoring the implementation classes of java.lang.constant
> into a new package jdk.internal.constant to enable sharing some trusted
> static factory methods with users elsewhere in java.base, such as
> java.lang.invoke and java.lang.classfile. The refactoring also adds
On Tue, 14 May 2024 11:19:36 GMT, Daniel Fuchs wrote:
>> @dfuch You mean not loading the whole batch but only individual classes, as
>> need arises?
>
> yes - I do not know if loading all the classes in one batch could be an issue
> at startup (I'd expect Random to be loaded early) - but if it
> ClassFile API `jdk.internal.classfile.verifier.VerifierImpl` performed only
> bytecode-level class verification.
> This patch adds `jdk.internal.classfile.verifier.ParserVerifier` with
> additional class checks inspired by
> `hotspot/share/classfile/classFileParser.cpp`.
>
> Also new
On Mon, 13 May 2024 17:12:33 GMT, Raffaello Giulietti
wrote:
>> Not sure if that's an issue - but if you wanted/needed to delay the loading
>> of those random generator classes that will not be used until something
>> actually wants to use them, you could consider using a `Supplier> extends
On Mon, 13 May 2024 17:31:25 GMT, Chen Liang wrote:
>> Adam Sotona has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - fixed error thrown by VerifierImpl
>> - applied suggested changes
>
>
On Mon, 13 May 2024 17:22:07 GMT, Maurizio Cimadamore
wrote:
>> Adam Sotona has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - fixed error thrown by VerifierImpl
>> - applied suggested changes
>
>
On Mon, 13 May 2024 17:21:03 GMT, Maurizio Cimadamore
wrote:
>> Adam Sotona has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - fixed error thrown by VerifierImpl
>> - applied suggested changes
>
>
On Mon, 13 May 2024 21:14:26 GMT, Stuart Marks wrote:
> Hm, I don't think we want to add any synchronized blocks within a shutdown
> hook. If a thread is blocked reading from the console, it will hold readLock;
> if the JVM is then shut down using a signal, it will run shutdown hooks, and
>
On Mon, 13 May 2024 17:17:40 GMT, Maurizio Cimadamore
wrote:
>> Adam Sotona has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - fixed error thrown by VerifierImpl
>> - applied suggested changes
>
>
On Tue, 14 May 2024 08:51:57 GMT, Aggelos Biboudis
wrote:
>> Adam Sotona has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - fixed error thrown by VerifierImpl
>> - applied suggested changes
>
>
On Tue, 14 May 2024 08:30:56 GMT, Aggelos Biboudis
wrote:
>> Adam Sotona has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - fixed error thrown by VerifierImpl
>> - applied suggested changes
>
>
On Thu, 9 May 2024 10:11:22 GMT, Adam Sotona wrote:
>> ClassFile API `jdk.internal.classfile.verifier.VerifierImpl` performed only
>> bytecode-level class verification.
>> This patch adds `jdk.internal.classfile.verifier.ParserVerifier` with
>> additional class checks inspired by
>>
On Fri, 10 May 2024 08:50:07 GMT, Claes Redestad wrote:
>> This PR suggests refactoring the implementation classes of
>> java.lang.constant into a new package jdk.internal.constant to enable
>> sharing some trusted static factory methods with users elsewhere in
>> java.base, such as
On Thu, 9 May 2024 10:11:22 GMT, Adam Sotona wrote:
>> ClassFile API `jdk.internal.classfile.verifier.VerifierImpl` performed only
>> bytecode-level class verification.
>> This patch adds `jdk.internal.classfile.verifier.ParserVerifier` with
>> additional class checks inspired by
>>
On Mon, 6 May 2024 18:24:25 GMT, Adam Sotona wrote:
>> Hi,
>> During performance optimization work on Class-File API as JDK lambda
>> generator we found some static initialization killers.
>> One of them is `java.lang.classfile.Attributes` with tens of static fields
>> initialized with
On Mon, 13 May 2024 17:35:39 GMT, Chen Liang wrote:
>> Is this method only supposed to check the attribute size? It would be nice
>> perhaps to enhance this to enforce more structural constraints - I added a
>> couple of comments in that direction, but there's many more (e.g. for
>> instance
On Mon, 13 May 2024 23:59:17 GMT, Viktor Klang wrote:
>> This change adds wrapping of the CancellationException produced by
>> CompletableFuture::get() and CompletableFuture::join() to add more
>> diagnostic information and align better with FutureTask.
>>
>> Running the sample code from the
On Tue, 14 May 2024 07:14:09 GMT, Thomas Stuefe wrote:
> but it does not state explicitly that an exception is thrown on every error,
> or whether there are cases where the API can return NULL but not throw an
> exception, or vice versa.
>
> So, I'd check for both. Or, if we think that both
On Mon, 13 May 2024 18:01:25 GMT, Sonia Zaldana Calles
wrote:
> > This mostly looks good. I'm just puzzled CHECK_EXCEPTION_NULL_FAIL. The JNI
> > functions GetStaticMethodID, GetMethodID and NewObject return NULL with a
> > pending exception when they fail. So I would expect
> >
82 matches
Mail list logo
