Re: RFR: 8334895: OpenJDK fails to configure on linux aarch64 when CDS is disabled after JDK-8331942 [v3]

2024-06-26 Thread Erik Joelsson
On Tue, 25 Jun 2024 19:30:26 GMT, Vladimir Petko wrote: >> This PR sets COMPATIBLE_CDS_ALIGNMENT_DEFAULT to auto for aarch64. >> This allows to avoid configure error on arm64: >> >> $ sh configure --disable-jvm-feature-cds >> ... >> checking if CDS archive is available... no (CDS is disabled) >

Re: RFR: 8331553: Windows JVM leaks Event and Thread handles when multiple threads are used [v2]

2024-06-26 Thread David Holmes
On Tue, 25 Jun 2024 18:23:18 GMT, Daniel Jeliński wrote: > With the new implementation, it wakes up much more frequently, Why? The number of unparks is unchanged. Are we seeing spurious unparks that are consuming too much CPU? - PR Comment: https://git.openjdk.org/jdk/pull/19778

Re: RFR: 8331553: Windows JVM leaks Event and Thread handles when multiple threads are used [v2]

2024-06-26 Thread Daniel Jeliński
On Wed, 19 Jun 2024 16:50:22 GMT, Daniel Jeliński wrote: >> We use 2 ParkEvent instances per thread. The ParkEvent objects are never >> freed, but they are recycled when a thread dies, so the number of live >> ParkEvent instances is proportional to the maximum number of threads that >> were li

Re: RFR: 8331553: Windows JVM leaks Event and Thread handles when multiple threads are used [v2]

2024-06-26 Thread David Holmes
On Wed, 26 Jun 2024 07:48:54 GMT, Daniel Jeliński wrote: > the waiting thread wakes up, but still needs to compete with the notifying > thread for the monitor. No, a notified thread is moved from the wait-queue to the monitor-entry queue. It is only unparked once the notifier thread releases

Re: RFR: 8331553: Windows JVM leaks Event and Thread handles when multiple threads are used [v2]

2024-06-26 Thread Daniel Jeliński
On Wed, 19 Jun 2024 16:50:22 GMT, Daniel Jeliński wrote: >> We use 2 ParkEvent instances per thread. The ParkEvent objects are never >> freed, but they are recycled when a thread dies, so the number of live >> ParkEvent instances is proportional to the maximum number of threads that >> were li

Re: RFR: 8334618: ubsan: support setting additional ubsan check options [v4]

2024-06-26 Thread Lutz Schmidt
On Tue, 25 Jun 2024 11:20:38 GMT, Matthias Baesken wrote: >> Sometimes it would be helpful to have configure-support for adding >> additional ubsan check options. >> E.g. support new configure option >> '--with-additional-ubsan-checks=' . > > Matthias Baesken has updated the pull request increm

Integrated: 8334618: ubsan: support setting additional ubsan check options

2024-06-26 Thread Matthias Baesken
On Thu, 20 Jun 2024 11:31:05 GMT, Matthias Baesken wrote: > Sometimes it would be helpful to have configure-support for adding additional > ubsan check options. > E.g. support new configure option > '--with-additional-ubsan-checks=' . This pull request has now been integrated. Changeset: efb9

Re: RFR: 8334618: ubsan: support setting additional ubsan check options [v4]

2024-06-26 Thread Matthias Baesken
On Tue, 25 Jun 2024 11:20:38 GMT, Matthias Baesken wrote: >> Sometimes it would be helpful to have configure-support for adding >> additional ubsan check options. >> E.g. support new configure option >> '--with-additional-ubsan-checks=' . > > Matthias Baesken has updated the pull request increm

Re: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v8]

2024-06-26 Thread Andrew Haley
On Mon, 24 Jun 2024 15:37:43 GMT, Hamlin Li wrote: >> Hi, >> Can you help to review the patch? >> This pr is based on previous work and discussion in [pr >> 16234](https://github.com/openjdk/jdk/pull/16234), [pr >> 18294](https://github.com/openjdk/jdk/pull/18294). >> >> Compared with previous

Re: [jdk23] RFR: 8333583: Crypto-XDH.generateSecret regression after JDK-8329538

2024-06-26 Thread Sandhya Viswanathan
On Tue, 25 Jun 2024 23:50:20 GMT, Volodymyr Paprotski wrote: > Hi all, > > This pull request contains a backport of commit > [f101e153](https://github.com/openjdk/jdk/commit/f101e153cee68750fcf1f12da10e29806875b522) > from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The com

[jdk23] Integrated: 8333583: Crypto-XDH.generateSecret regression after JDK-8329538

2024-06-26 Thread Volodymyr Paprotski
On Tue, 25 Jun 2024 23:50:20 GMT, Volodymyr Paprotski wrote: > Hi all, > > This pull request contains a backport of commit > [f101e153](https://github.com/openjdk/jdk/commit/f101e153cee68750fcf1f12da10e29806875b522) > from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The com

Re: RFR: 8334031: Generated JfrNativeSettings seems off

2024-06-26 Thread Erik Gahlin
On Tue, 25 Jun 2024 18:55:14 GMT, Robert Toyonaga wrote: > This PR changes GenerateJfrFiles.java so that the generated > `JfrNativeSettings` union does not include JFR structs.`JfrNativeSettings` is > meant to hold the settings for JFR events, but previously also included JFR > structs such as

Re: RFR: 8309634: Resolve CONSTANT_MethodRef at CDS dump time [v2]

2024-06-26 Thread Matias Saavedra Silva
On Wed, 26 Jun 2024 03:11:41 GMT, Ioi Lam wrote: >> Resolve `CONSTANT_MethodRef` entries during CDS dump time to improve >> start-up performance. >> >> - This PR uses the same framework introduced in #19355 and just added >> handling for methods. >> - Support for getstatic/putstatic/invokestat

Re: RFR: 8334031: Generated JfrNativeSettings seems off

2024-06-26 Thread Robert Toyonaga
On Wed, 26 Jun 2024 17:00:23 GMT, Erik Gahlin wrote: > All types in JFR is assigned an ID, regardless if they are events or a > structs. If we are going to index into the array, with the event type ID, > must not the holes be filled with something? Or are all native event type IDs > first? It

Re: RFR: 8334031: Generated JfrNativeSettings seems off

2024-06-26 Thread Erik Gahlin
On Tue, 25 Jun 2024 18:55:14 GMT, Robert Toyonaga wrote: > This PR changes GenerateJfrFiles.java so that the generated > `JfrNativeSettings` union does not include JFR structs.`JfrNativeSettings` is > meant to hold the settings for JFR events, but previously also included JFR > structs such as

Re: RFR: 8334031: Generated JfrNativeSettings seems off

2024-06-26 Thread Robert Toyonaga
On Tue, 25 Jun 2024 18:55:14 GMT, Robert Toyonaga wrote: > This PR changes GenerateJfrFiles.java so that the generated > `JfrNativeSettings` union does not include JFR structs.`JfrNativeSettings` is > meant to hold the settings for JFR events, but previously also included JFR > structs such as

Re: RFR: 8334031: Generated JfrNativeSettings seems off

2024-06-26 Thread Erik Gahlin
On Tue, 25 Jun 2024 18:55:14 GMT, Robert Toyonaga wrote: > This PR changes GenerateJfrFiles.java so that the generated > `JfrNativeSettings` union does not include JFR structs.`JfrNativeSettings` is > meant to hold the settings for JFR events, but previously also included JFR > structs such as

Re: RFR: 8331553: Windows JVM leaks Event and Thread handles when multiple threads are used [v2]

2024-06-26 Thread David Holmes
On Wed, 19 Jun 2024 16:50:22 GMT, Daniel Jeliński wrote: >> We use 2 ParkEvent instances per thread. The ParkEvent objects are never >> freed, but they are recycled when a thread dies, so the number of live >> ParkEvent instances is proportional to the maximum number of threads that >> were li

Re: RFR: 8334763: --enable-asan: assert(_thread->is_in_live_stack((address)this)) failed: not on stack? [v6]

2024-06-26 Thread Jan Kratochvil
> fastdebug: > > > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error > (/home/azul/azul/openjdk-git/src/hotspot/share/runtime/handles.inline.hpp:77), > pid=878152, tid=878158 > # assert(_thread->is_in_live_stack((address)this)) failed: not on stack? > #

Re: RFR: 8334763: --enable-asan: assert(_thread->is_in_live_stack((address)this)) failed: not on stack? [v5]

2024-06-26 Thread Jan Kratochvil
On Mon, 24 Jun 2024 18:43:51 GMT, Kim Barrett wrote: >> Jan Kratochvil has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Change the comment >>- suggested by Thomas Stuefe > > make/autoconf/jdk-options.m4 line 449: > >> 447: