On Fri, 12 Jul 2024 06:29:34 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
>
> 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
On Fri, 12 Jul 2024 19:18:09 GMT, Kim Barrett wrote:
> This should be using `os::snprintf` rather than `snprintf`. Rationale is in
> the comment here:
>
> https://github.com/openjdk/jdk/blob/1f6e106b45e5109224e13d70f1a40c9e666ec2ab/src/hotspot/share/runtime/os.cpp#L118-L126
>
> And yes, I
On Sat, 13 Jul 2024 00:39:02 GMT, Chris Plummer wrote:
>> Alex Menkov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> feedback
>
> test/hotspot/jtreg/serviceability/attach/LongArgTest.java line 79:
>
>> 77: // Value length
On Fri, 12 Jul 2024 20:25:21 GMT, Chris Plummer wrote:
>> Alex Menkov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> feedback
>
> test/hotspot/jtreg/serviceability/attach/LongArgTest.java line 98:
>
>> 96:
>> 97: if
On Fri, 12 Jul 2024 21:03:26 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
>
>
On Fri, 12 Jul 2024 22:36:56 GMT, Daniel D. Daugherty
wrote:
> Is there any chance that all the `Breakpint` typos can be fixed?
There was only one and I fixed it already.
-
PR Comment: https://git.openjdk.org/jdk/pull/20088#issuecomment-2226537454
On Fri, 12 Jul 2024 03:24:42 GMT, SendaoYan wrote:
> Hi all,
> Test TestClhsdbJstackLock.java/TestJhsdbJstackLock.java fails with -Xcomp
> after [JDK-8335743](https://bugs.openjdk.org/browse/JDK-8335743). I think the
> new failures was testcase bug.
>
>
On Wed, 3 Jul 2024 13:58:51 GMT, Kevin Walls wrote:
> CmdLine::is_executable() looks wrong, surely an empty line is not executable.
>
> With this change, in DCmd::parse_and_execute() we will avoid needlessly
> entering the code block to try and execute the command.
>
> DCmd tests all good:
>
On Fri, 12 Jul 2024 17:02:56 GMT, Chris Plummer wrote:
>> The original code had 2 vm.resume() - one on them to match vm.suspend() and
>> 2nd one to allow debugee to continue on error.
>> Now we have 3 vm.resume() - one is to match vm.suspend() (line 377) and 2
>> conditional (on error).
>>
On Thu, 11 Jul 2024 22:36:05 GMT, Chris Plummer wrote:
>> The test hits a breakpoint on thread2 with SUSPEND_EVENT_THREAD policy, so
>> only thread2 is suspended. It then does a vm.suspend(), which suspends all
>> threads and bumps the suspendCount of thread2 up to 2. It then does an
>>
On 7/12/24 12:06 PM, Ron Pressler wrote:
On 10 Jul 2024, at 16:37, Jaroslav Bachorik wrote:
This may not always be possible. Some systems have rather complex and inlexible
launchers - for example Apache Spark with its clusters, drivers and executors
and automatic distribution of
> 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
Alex Menkov has updated the pull request incrementally with one
On Fri, 12 Jul 2024 06:27:46 GMT, Serguei Spitsyn wrote:
>> Alex Menkov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> feedback
>
> src/jdk.attach/windows/native/libattach/VirtualMachineImpl.c line 57:
>
>> 55:
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
The fix
On Fri, 12 Jul 2024 06:29:34 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
>
> On 10 Jul 2024, at 16:37, Jaroslav Bachorik wrote:
>
> This may not always be possible. Some systems have rather complex and
> inlexible launchers - for example Apache Spark with its clusters, drivers and
> executors and automatic distribution of resources. For that system, if one
> needs
On Fri, 12 Jul 2024 15:58:56 GMT, Roman Kennke wrote:
>> src/hotspot/share/runtime/synchronizer.cpp line 390:
>>
>>> 388:
>>> 389: static bool useHeavyMonitors() {
>>> 390: #if defined(X86) || defined(AARCH64) || defined(PPC64) ||
>>> defined(RISCV64) || defined(S390)
>>
>> Why are those
On Thu, 4 Jul 2024 10:08:30 GMT, Kevin Walls wrote:
> There are two similarly names tests.
> Recently:
> JDK-8335124: com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java failed
> with CPU time out of expected range
> ...made a simple change to try and avoid noisy test failures. The same
On Thu, 4 Jul 2024 10:08:30 GMT, Kevin Walls wrote:
> There are two similarly names tests.
> Recently:
> JDK-8335124: com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java failed
> with CPU time out of expected range
> ...made a simple change to try and avoid noisy test failures. The same
On Fri, 12 Jul 2024 08:02:31 GMT, Alex Menkov wrote:
>> First just to clarify a general JDI feature about thread suspending and
>> resuming. You can undo a ThreadReference.suspend() or a thread suspended as
>> the result of an event by dong a vm.resume(). This is documented in the JDI
>> API
On Mon, 8 Jul 2024 21:09:49 GMT, Kevin Walls wrote:
>> test/jdk/java/lang/management/ThreadMXBean/ThreadCpuTime.java line 239:
>>
>>> 237: " > ThreadUserTime = " + utime2);
>>> 238: }
>>> 239: */
>>
>> Shouldn't this be uncommented and this bit of testing
On Thu, 4 Jul 2024 10:08:30 GMT, Kevin Walls wrote:
> There are two similarly names tests.
> Recently:
> JDK-8335124: com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java failed
> with CPU time out of expected range
> ...made a simple change to try and avoid noisy test failures. The same
On Fri, 12 Jul 2024 15:56:59 GMT, Roman Kennke wrote:
>> Axel Boldt-Christmas has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Update arguments.cpp
>
> src/hotspot/share/runtime/synchronizer.cpp line 390:
>
>> 388:
>> 389: static bool
On Tue, 9 Jul 2024 20:43:06 GMT, Coleen Phillimore wrote:
>> Axel Boldt-Christmas has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Add JVMCI symbol exports
>> - Revert "More graceful JVMCI VM option interaction"
>>
>>This
On Fri, 12 Jul 2024 05:57: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
>>
On Wed, Jul 10, 2024 at 5:53 PM Alan Bateman
wrote:
> On 10/07/2024 16:37, Jaroslav Bachorik wrote:
>
> :
>
> This may not always be possible. Some systems have rather complex and
> inlexible launchers - for example Apache Spark with its clusters, drivers
> and executors and automatic
On Fri, 12 Jul 2024 12:06:05 GMT, Andrew Haley wrote:
>> src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 343:
>>
>>> 341: const Register t3_owner = t3;
>>> 342: const ByteSize monitor_tag = in_ByteSize(UseObjectMonitorTable ? 0
>>> : checked_cast(markWord::monitor_value));
> 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 looser
> semantics to use this displaced data. In Lilliput this data
On Mon, 8 Jul 2024 16:18:22 GMT, Albert Mingkun Yang wrote:
> Similar cleanup as https://github.com/openjdk/jdk/pull/19056 but in Parallel.
> As a result, the corresponding code in `SerialHeap` and
> `ParallelScavengeHeap` share much similarity.
>
> The easiest way to review is to start from
On Thu, 11 Jul 2024 18:06:34 GMT, Albert Mingkun Yang wrote:
>> Similar cleanup as https://github.com/openjdk/jdk/pull/19056 but in
>> Parallel. As a result, the corresponding code in `SerialHeap` and
>> `ParallelScavengeHeap` share much similarity.
>>
>> The easiest way to review is to start
On Fri, 12 Jul 2024 10:54:23 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
>>
On Thu, 11 Jul 2024 18:06:34 GMT, Albert Mingkun Yang wrote:
>> Similar cleanup as https://github.com/openjdk/jdk/pull/19056 but in
>> Parallel. As a result, the corresponding code in `SerialHeap` and
>> `ParallelScavengeHeap` share much similarity.
>>
>> The easiest way to review is to start
On Tue, 9 Jul 2024 12:17:25 GMT, Alan Bateman wrote:
>> @AlanBateman would you mind having a quick look at this trivial,
>> documentation-only PR and let me know if you're OK with it?
>>
>> Thank you and best regards,
>> Volker
>
>> @AlanBateman would you mind having a quick look at this
On Wed, 3 Jul 2024 16:14:31 GMT, Volker Simonis wrote:
> Since Java 5 the `java.lang.instrument` package provides services that allow
> Java programming language agents to instrument (i.e. modify the bytecode) of
> programs running on the Java Virtual Machine. The `java.lang.instrument`
>
On Fri, 12 Jul 2024 09:40:45 GMT, Roman Kennke wrote:
>> Axel Boldt-Christmas has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Update arguments.cpp
>
> src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 343:
>
>> 341: const
On Fri, 12 Jul 2024 09:53:11 GMT, Roman Kennke wrote:
> When you say 'This patch has been evaluated to be performance neutral when
> UseObjectMonitorTable is turned off (the default).' - what does the
> performance look like with +UOMT? How does it compare to -UOMT?
Most benchmarks are
On Fri, 12 Jul 2024 09:32:44 GMT, Roman Kennke wrote:
>> Axel Boldt-Christmas has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Update arguments.cpp
>
> src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 318:
>
>> 316:
>> 317:
> 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 looser
> semantics to use this displaced data. In Lilliput this data
On Fri, 12 Jul 2024 05:57: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
>>
On Fri, 12 Jul 2024 01:22:28 GMT, Guoxiong Li wrote:
>> src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 446:
>>
>>> 444: }
>>> 445: return result; // Could be null if we are out of space.
>>> 446: }
>>
>> I notice the method `PSOldGen::allocate` can expand the size of the old
On Fri, 12 Jul 2024 05:57: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
>>
On Wed, 3 Jul 2024 13:58:51 GMT, Kevin Walls wrote:
> CmdLine::is_executable() looks wrong, surely an empty line is not executable.
>
> With this change, in DCmd::parse_and_execute() we will avoid needlessly
> entering the code block to try and execute the command.
>
> DCmd tests all good:
>
On Wed, 10 Jul 2024 20:10:13 GMT, Volker Simonis wrote:
>> Since Java 5 the `java.lang.instrument` package provides services that allow
>> Java programming language agents to instrument (i.e. modify the bytecode) of
>> programs running on the Java Virtual Machine. The `java.lang.instrument`
On Wed, 10 Jul 2024 20:10:13 GMT, Volker Simonis wrote:
>> Since Java 5 the `java.lang.instrument` package provides services that allow
>> Java programming language agents to instrument (i.e. modify the bytecode) of
>> programs running on the Java Virtual Machine. The `java.lang.instrument`
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 this PR addresses those issues by updating the test specific
On Fri, 12 Jul 2024 02:23:02 GMT, Serguei Spitsyn wrote:
>> Kevin Walls has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> formatting
>
> test/hotspot/jtreg/vmTestbase/nsk/monitoring/MemoryNotificationInfo/from/from001.java
> line 171:
>
> Short version:
> Stop testing this test with -Xcomp by adding requires vm.compMode != "Xcomp"
>
> Make additional typo fixes and tidyups while here, it's just shocking.
>
> TestDescription.java contains the test definition, so the "requires" goes
> there, with a comment.
>
> Updates to
On Wed, 10 Jul 2024 16:56:37 GMT, Volker Simonis wrote:
>> src/java.instrument/share/classes/java/lang/instrument/ClassFileTransformer.java
>> line 179:
>>
>>> 177: * This means that a {@link LinkageError} triggered during
>>> transformation of
>>> 178: * {@code C} in a class {@code D} not
On Fri, 12 Jul 2024 08:27:47 GMT, Alex Menkov wrote:
> > Fix the testcase bug, I think it's not need the 2rd reviewer.
>
> My bad for hasty sponsorship. General rules are applied to test fixes - 2
> reviewers and at least 24 hours for review.
Sorry for hasty integrate, I will pay attention
On Fri, 12 Jul 2024 06:34:57 GMT, SendaoYan wrote:
> Fix the testcase bug, I think it's not need the 2rd reviewer.
My bad for hasty sponsorship.
General rules are applied to test fixes - 2 reviewers and at least 24 hours for
review.
-
PR Comment:
On Fri, 12 Jul 2024 03:24:42 GMT, SendaoYan wrote:
> Hi all,
> Test TestClhsdbJstackLock.java/TestJhsdbJstackLock.java fails with -Xcomp
> after [JDK-8335743](https://bugs.openjdk.org/browse/JDK-8335743). I think the
> new failures was testcase bug.
>
>
On Fri, 5 Jul 2024 14:06:39 GMT, Kevin Walls wrote:
> The test
> test/jdk/javax/management/remote/mandatory/connection/RMIConnector_NPETest.java
> should be removed.
>
> This test was added when 6984520 was fixed in 6u25. It has been
> problemlisted since JDK-8267123 removed RMI Activation
On Fri, 5 Jul 2024 14:06:39 GMT, Kevin Walls wrote:
> The test
> test/jdk/javax/management/remote/mandatory/connection/RMIConnector_NPETest.java
> should be removed.
>
> This test was added when 6984520 was fixed in 6u25. It has been
> problemlisted since JDK-8267123 removed RMI Activation
On Fri, 12 Jul 2024 03:24:42 GMT, SendaoYan wrote:
> Hi all,
> Test TestClhsdbJstackLock.java/TestJhsdbJstackLock.java fails with -Xcomp
> after [JDK-8335743](https://bugs.openjdk.org/browse/JDK-8335743). I think the
> new failures was testcase bug.
>
>
On Fri, 12 Jul 2024 03:24:42 GMT, SendaoYan wrote:
> Hi all,
> Test TestClhsdbJstackLock.java/TestJhsdbJstackLock.java fails with -Xcomp
> after [JDK-8335743](https://bugs.openjdk.org/browse/JDK-8335743). I think the
> new failures was testcase bug.
>
>
On Fri, 12 Jul 2024 04:08:25 GMT, Chris Plummer wrote:
>> test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/resume/resume001.java
>> line 382:
>>
>>> 380: if (expresult != returnCode0) {
>>> 381: vm.resume();
>>> 382: vm.resume(); // for case
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 C99 and
On Fri, 12 Jul 2024 03:24:42 GMT, SendaoYan wrote:
> Hi all,
> Test TestClhsdbJstackLock.java/TestJhsdbJstackLock.java fails with -Xcomp
> after [JDK-8335743](https://bugs.openjdk.org/browse/JDK-8335743). I think the
> new failures was testcase bug.
>
>
On Fri, 12 Jul 2024 03:24:42 GMT, SendaoYan wrote:
> Hi all,
> Test TestClhsdbJstackLock.java/TestJhsdbJstackLock.java fails with -Xcomp
> after [JDK-8335743](https://bugs.openjdk.org/browse/JDK-8335743). I think the
> new failures was testcase bug.
>
>
On Thu, 11 Jul 2024 22:36:05 GMT, Chris Plummer wrote:
>> The test hits a breakpoint on thread2 with SUSPEND_EVENT_THREAD policy, so
>> only thread2 is suspended. It then does a vm.suspend(), which suspends all
>> threads and bumps the suspendCount of thread2 up to 2. It then does an
>>
On Mon, 8 Jul 2024 11:06:45 GMT, Matthias Baesken wrote:
> Unfortunately those 2 tests fail now on Linux Alpine (x86_64) :
> serviceability/dcmd/vm/SystemDumpMapTest.java
>
> Missing patterns in dump:
> 0x\\p{XDigit}+-0x\\p{XDigit}+ +\\d+ +[rwsxp-]+ +\\d+ +\\d+
> +(4K|8K|16K|64K|2M|16M|64M)
62 matches
Mail list logo
