On Fri, 12 Jul 2024 20:37:49 GMT, Alex Menkov wrote:
>> test/hotspot/jtreg/serviceability/attach/LongArgTest.java line 94:
>>
>>> 92: HotSpotVirtualMachine vm =
>>> (HotSpotVirtualMachine)VirtualMachine.attach(String.valueOf(app.getPid()));
>>> 93:
>>> 94: if (setFlag(v
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
> gcc,
> 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 know
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 excee
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
>
> Alex
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.
>
> https://github.com/openjdk/jdk/blob/627a
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:
> m
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).
>> Theo
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
>> eventS
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 resources
> 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 add
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: doPrivilegedOpenProcess(
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 look
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
> gcc,
> 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 if-d
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 fix
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 fix
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 s
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 restore
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 fix
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 u
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 rever
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
>> l
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 distributio
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 als
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 t
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
>> l
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 trivia
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`
> func
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 R
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 unaffec
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 als
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
>> l
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
>> l
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:
> m
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
`Class
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 from00
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 d
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 nex
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: https://git.openjdk.org/jdk/pull/2
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.
>
> https://github.com/openjdk/jdk/blob/627a
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.
>
> https://github.com/openjdk/jdk/blob/627a
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.
>
> https://github.com/openjdk/jdk/blob/627a
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 err
58 matches
Mail list logo
