Re: RFR: 8315884: New Object to ObjectMonitor mapping [v9]

2024-07-16 Thread David Holmes
On Mon, 15 Jul 2024 00:50:30 GMT, Axel Boldt-Christmas wrote: >> When inflating a monitor the `ObjectMonitor*` is written directly over the >> `markWord` and any overwritten data is displaced into a displaced >> `markWord`. This is problematic for concurrent GCs which needs extra care or >> l

Re: RFR: 8315884: New Object to ObjectMonitor mapping [v9]

2024-07-16 Thread David Holmes
On Mon, 15 Jul 2024 00:50:30 GMT, Axel Boldt-Christmas wrote: >> When inflating a monitor the `ObjectMonitor*` is written directly over the >> `markWord` and any overwritten data is displaced into a displaced >> `markWord`. This is problematic for concurrent GCs which needs extra care or >> l

Re: RFR: 8315884: New Object to ObjectMonitor mapping [v9]

2024-07-16 Thread David Holmes
On Wed, 17 Jul 2024 06:39:14 GMT, David Holmes wrote: >> Axel Boldt-Christmas has updated the pull request incrementally with 10 >> additional commits since the last revision: >> >> - Remove try_read >> - Add explicit to single parameter constructors >> - Remove superfluous access specifier

Re: RFR: 8315884: New Object to ObjectMonitor mapping [v9]

2024-07-16 Thread David Holmes
On Mon, 15 Jul 2024 00:50:30 GMT, Axel Boldt-Christmas wrote: >> When inflating a monitor the `ObjectMonitor*` is written directly over the >> `markWord` and any overwritten data is displaced into a displaced >> `markWord`. This is problematic for concurrent GCs which needs extra care or >> l

Re: RFR: 8315884: New Object to ObjectMonitor mapping [v9]

2024-07-16 Thread David Holmes
On Mon, 15 Jul 2024 00:50:30 GMT, Axel Boldt-Christmas wrote: >> When inflating a monitor the `ObjectMonitor*` is written directly over the >> `markWord` and any overwritten data is displaced into a displaced >> `markWord`. This is problematic for concurrent GCs which needs extra care or >> l

Integrated: 8334167: Test java/lang/instrument/NativeMethodPrefixApp.java timed out

2024-07-16 Thread Jaikiran Pai
On Fri, 12 Jul 2024 09:22:54 GMT, Jaikiran Pai wrote: > Can I please get a review of this test-only change which proposes to fix the > test timeout reported in https://bugs.openjdk.org/browse/JDK-8334167? > > The JBS issue has comments which explains what causes the timeout. The commit > in th

Re: RFR: 8335921: Fix HotSpot VM build without JVMTI

2024-07-16 Thread Vladimir Kozlov
On Wed, 17 Jul 2024 04:52:35 GMT, David Holmes wrote: >> Citing David Holmes from bug report: >> "We provided the ability to leave out certain VM services (JVMTI, GC's other >> than serial, ...) as part of the design of the MinimalVM to support Java SE >> Embedded, along with the Compact Profil

Re: RFR: 8335921: Fix HotSpot VM build without JVMTI

2024-07-16 Thread Vladimir Kozlov
On Wed, 17 Jul 2024 03:37:36 GMT, Vladimir Kozlov wrote: > Citing David Holmes from bug report: > "We provided the ability to leave out certain VM services (JVMTI, GC's other > than serial, ...) as part of the design of the MinimalVM to support Java SE > Embedded, along with the Compact Profile

Re: RFR: 8336289: Obliterate most references to _snprintf in the Windows JDK [v3]

2024-07-16 Thread David Holmes
On Tue, 16 Jul 2024 08:59:20 GMT, Julian Waters wrote: >> snprintf has been available for all officially and unofficially supported >> compilers for Windows, Visual Studio since version 2015 and gcc since, well, >> forever. snprintf is conforming to C99 since the start when compiling using >>

Re: RFR: 8335921: Fix HotSpot VM build without JVMTI

2024-07-16 Thread David Holmes
On Wed, 17 Jul 2024 03:37:36 GMT, Vladimir Kozlov wrote: > Citing David Holmes from bug report: > "We provided the ability to leave out certain VM services (JVMTI, GC's other > than serial, ...) as part of the design of the MinimalVM to support Java SE > Embedded, along with the Compact Profile

RFR: 8335921: Fix HotSpot VM build without JVMTI

2024-07-16 Thread Vladimir Kozlov
Citing David Holmes from bug report: "We provided the ability to leave out certain VM services (JVMTI, GC's other than serial, ...) as part of the design of the MinimalVM to support Java SE Embedded, along with the Compact Profiles of JDK 8. This manifested in the source code as a set of INCLUDE

Integrated: 8336420: Add JVMTI setfldw001 and setfmodw001 tests to Xcomp problem list

2024-07-16 Thread Chris Plummer
On Tue, 16 Jul 2024 18:56:53 GMT, Chris Plummer wrote: > The following two Xcomp problem list entries were removed: > > vmTestbase/nsk/jvmti/SetFieldAccessWatch/setfldw001/TestDescription.java > 8205957 generic-all > vmTestbase/nsk/jvmti/SetFieldModificationWatch/setfmodw001/TestDescription.jav

Re: RFR: 8336420: Add JVMTI setfldw001 and setfmodw001 tests to Xcomp problem list

2024-07-16 Thread Chris Plummer
On Tue, 16 Jul 2024 18:56:53 GMT, Chris Plummer wrote: > The following two Xcomp problem list entries were removed: > > vmTestbase/nsk/jvmti/SetFieldAccessWatch/setfldw001/TestDescription.java > 8205957 generic-all > vmTestbase/nsk/jvmti/SetFieldModificationWatch/setfmodw001/TestDescription.jav

Re: RFR: 8336420: Add JVMTI setfldw001 and setfmodw001 tests to Xcomp problem list

2024-07-16 Thread Daniel D . Daugherty
On Tue, 16 Jul 2024 18:56:53 GMT, Chris Plummer wrote: > The following two Xcomp problem list entries were removed: > > vmTestbase/nsk/jvmti/SetFieldAccessWatch/setfldw001/TestDescription.java > 8205957 generic-all > vmTestbase/nsk/jvmti/SetFieldModificationWatch/setfmodw001/TestDescription.jav

RFR: 8336420: Added JVMTI setfldw001 and setfmodw001 tests to Xcomp problem list

2024-07-16 Thread Chris Plummer
The following two Xcomp problem list entries need were removed: vmTestbase/nsk/jvmti/SetFieldAccessWatch/setfldw001/TestDescription.java 8205957 generic-all vmTestbase/nsk/jvmti/SetFieldModificationWatch/setfmodw001/TestDescription.java 8205957 linux-x64,windows-x64 Each of these tests now has

Integrated: 8334169: Long arguments of attach operation are silently truncated on Windows

2024-07-16 Thread Alex Menkov
On Wed, 19 Jun 2024 01:50:30 GMT, Alex Menkov wrote: > The change fixes a bug in Attach API implementation on Windows when > argument(s) are longer than 1023 bytes > > testing: test/hotspot/jtreg/serviceability/attach, > test/jdk/com/sun/tools/attach on Oracle supported platforms This pull re

Integrated: 8335533: OutOfMemoryError: Metaspace observed again on AIX in test RedefineLeakThrowable.java after JDK-8294960

2024-07-16 Thread Christoph Langer
On Wed, 10 Jul 2024 09:14:11 GMT, Christoph Langer wrote: > The change of JDK-8294960 has brought an increase of required metaspace for > this test on AIX which seems to go beyond 23m in most cases. So I propose > another slight increment. > > Why AIX needs more metaspace compared to other pla

Re: RFR: 8315884: New Object to ObjectMonitor mapping [v9]

2024-07-16 Thread Roman Kennke
On Tue, 16 Jul 2024 12:37:43 GMT, Roman Kennke wrote: >> Axel Boldt-Christmas has updated the pull request incrementally with 10 >> additional commits since the last revision: >> >> - Remove try_read >> - Add explicit to single parameter constructors >> - Remove superfluous access specifier

Re: RFR: 8315884: New Object to ObjectMonitor mapping [v9]

2024-07-16 Thread Roman Kennke
On Mon, 15 Jul 2024 00:50:30 GMT, Axel Boldt-Christmas wrote: >> When inflating a monitor the `ObjectMonitor*` is written directly over the >> `markWord` and any overwritten data is displaced into a displaced >> `markWord`. This is problematic for concurrent GCs which needs extra care or >> l

Re: RFR: 8336289: Obliterate most references to _snprintf in the Windows JDK [v3]

2024-07-16 Thread Daniel Jeliński
On Tue, 16 Jul 2024 08:59:20 GMT, Julian Waters wrote: >> snprintf has been available for all officially and unofficially supported >> compilers for Windows, Visual Studio since version 2015 and gcc since, well, >> forever. snprintf is conforming to C99 since the start when compiling using >>

Re: RFR: 8336289: Obliterate most references to _snprintf in the Windows JDK [v2]

2024-07-16 Thread Kim Barrett
On Tue, 16 Jul 2024 08:52:01 GMT, Julian Waters wrote: >> src/jdk.jdwp.agent/windows/native/libjdwp/util_md.h line 32: >> >>> 30: #include /* for _MAx_PATH */ >>> 31: >>> 32: typedef unsigned long long UNSIGNED_JLONG; >> >> This change has nothing to do with _sprintf. Not sure why it's

Re: RFR: 8336289: Obliterate most references to _snprintf in the Windows JDK [v3]

2024-07-16 Thread Kim Barrett
On Tue, 16 Jul 2024 08:59:20 GMT, Julian Waters wrote: >> snprintf has been available for all officially and unofficially supported >> compilers for Windows, Visual Studio since version 2015 and gcc since, well, >> forever. snprintf is conforming to C99 since the start when compiling using >>

Re: RFR: 8334781: JFR crash: assert(((((JfrTraceIdBits::load(klass)) & ((JfrTraceIdEpoch::this_epoch_method_and_class_bits()))) != 0))) failed: invariant

2024-07-16 Thread Markus Grönlund
On Tue, 16 Jul 2024 00:05:36 GMT, Serguei Spitsyn wrote: >> Greetings, >> >> Please help review this adjustment, which fixes rare situations where >> methods that have been retransformed or redefined can be perceived as being >> tagged by JFR when they, in fact, are not. The fix unconditionall

Re: RFR: 8336289: Obliterate most references to _snprintf in the Windows JDK [v3]

2024-07-16 Thread Julian Waters
> snprintf has been available for all officially and unofficially supported > compilers for Windows, Visual Studio since version 2015 and gcc since, well, > forever. snprintf is conforming to C99 since the start when compiling using > gcc, and 2015 when using Visual Studio. Since it conforms to

Re: RFR: 8336289: Obliterate most references to _snprintf in the Windows JDK [v2]

2024-07-16 Thread Julian Waters
On Mon, 15 Jul 2024 16:30:02 GMT, Kim Barrett wrote: >> Julian Waters has updated the pull request incrementally with one additional >> commit since the last revision: >> >> USe os::snprintf in HotSpot > > src/jdk.jdwp.agent/windows/native/libjdwp/util_md.h line 32: > >> 30: #include /