On Sat, 27 Jul 2024 06:11:00 GMT, Thomas Stuefe wrote:
> > Also I would recommend to get approval from svc team reviewer.
>
> Who could this be, @plummercj ?
@kevinjwalls is on the svc team and has been involved in this review, and
@dholmes-ora, @lmesnik, and @AlanBateman all count as svc
JVMTI has a somewhat unique event called DataDumpRequest. One way it is
triggered is via the JVMTI.data_dump jcmd, which causes JVMTI to send the
DataDumpRequest event to all agents that have registered for the event
callback. The agent is free to do pretty much what it wants during the
On Sat, 27 Jul 2024 01:55:23 GMT, Chris Plummer wrote:
> The test is setting breakpoints on the wrong line numbers, which causes
> setting up the breakpoint to fail, but the test also has buggy error
> checking, so the test doesn't detect the failures and still passes
The test is setting breakpoints on the wrong line numbers, which causes setting
up the breakpoint to fail, but the test also has buggy error checking, so the
test doesn't detect the failures and still passes. I fixed the breakpoint line
numbers and the error checking. More details in the first
On Mon, 22 Jul 2024 20:32:35 GMT, Chris Plummer wrote:
> Fix deadlock with debug agent callbackLock. Details in first comment.
>
> Tested by running all jdi, jdwp, and jdb tests with and without virtual
> threads about 40 times. The testing was initially done with my hack to force
Fix deadlock with debug agent callbackLock. Details in first comment.
Tested by running all jdi, jdwp, and jdb tests with and without virtual threads
about 40 times. The testing was initially done with my hack to force the self
suspend (see the first comment in the CR), and then I did final
On Fri, 19 Jul 2024 18:41:10 GMT, Chris Plummer wrote:
> The test sometimes fails because the InterruptException doesn't arrive during
> the 100ms that the thread sleeps. My suspicion is that the interrupt is being
> delayed for some external reason, like temporary load on the
On Fri, 19 Jul 2024 18:41:10 GMT, Chris Plummer wrote:
> The test sometimes fails because the InterruptException doesn't arrive during
> the 100ms that the thread sleeps. My suspicion is that the interrupt is being
> delayed for some external reason, like temporary load on the
On Fri, 17 May 2024 19:32:31 GMT, Chris Plummer wrote:
>> This PR adds ranked monitor support to the debug agent. The debug agent has
>> a large number of monitors, and it's really hard to know which order to grab
>> them in, and for that matter which monitors might alre
On Fri, 19 Jul 2024 01:44:16 GMT, Chris Plummer wrote:
> Fix issue with `` argument.
This pull request has now been integrated.
Changeset: b144910e
Author: Chris Plummer
URL:
https://git.openjdk.org/jdk/commit/b144910ebb74be5a12dae57263f2a93452535f02
Stats: 1 line in 1 f
On Fri, 19 Jul 2024 01:44:16 GMT, Chris Plummer wrote:
> Fix issue with `` argument.
Thanks David and Thomas!
-
PR Comment: https://git.openjdk.org/jdk/pull/20246#issuecomment-2243584280
On Fri, 19 Jul 2024 01:44:16 GMT, Chris Plummer wrote:
> Fix issue with `` argument.
Can I get a 2nd review please? Thanks!
-
PR Comment: https://git.openjdk.org/jdk/pull/20246#issuecomment-2243506993
On Sat, 20 Jul 2024 06:33:09 GMT, Daniel Lundén wrote:
>> We are seeing quite a few timeouts for
>> `serviceability/sa/ClhsdbDumpheap.java` running with -Xcomp in testing,
>> possibly related to
>> [JDK-8324241](https://bugs.openjdk.org/browse/JDK-8324241). We should
>> disable running
On Thu, 18 Jul 2024 18:50:48 GMT, Chris Plummer wrote:
> The test is failing with an ObjectCollectedException. The test hits a
> SUSPEND_ALL breakpoint. It then uses JDI to allocate an Object on the
> debuggee side:
>
> testedObject = testedClass.newInstance(threa
On Fri, 19 Jul 2024 20:17:46 GMT, Sonia Zaldana Calles
wrote:
>> Hi all,
>>
>> This is a small patch to address
>> [8327054](https://bugs.openjdk.org/browse/JDK-8327054) making
>> `CodeCache::write_perf_map` aware of which output stream errors and warning
>> message should be going to.
>>
On Thu, 18 Jul 2024 18:50:48 GMT, Chris Plummer wrote:
> The test is failing with an ObjectCollectedException. The test hits a
> SUSPEND_ALL breakpoint. It then uses JDI to allocate an Object on the
> debuggee side:
>
> testedObject = testedClass.newInstance(threa
On Fri, 19 Jul 2024 15:07:39 GMT, Sonia Zaldana Calles
wrote:
> Hi all,
>
> This is a small patch to address
> [8327054](https://bugs.openjdk.org/browse/JDK-8327054) making
> `CodeCache::write_perf_map` aware of which output stream errors and warning
> message should be going to.
>
>
The test sometimes fails because the InterruptException doesn't arrive during
the 100ms that the thread sleeps. My suspicion is that the interrupt is being
delayed for some external reason, like temporary load on the host. I'm bumping
the sleep period to 10s to hopefully avoid such an issue.
On Fri, 19 Jul 2024 11:50:03 GMT, Daniel Lundén wrote:
>> We are seeing quite a few timeouts for
>> `serviceability/sa/ClhsdbDumpheap.java` running with -Xcomp in testing,
>> possibly related to
>> [JDK-8324241](https://bugs.openjdk.org/browse/JDK-8324241). We should
>> disable running
Fix issue with `` argument.
-
Commit messages:
- Fix quoting of pid argument
Changes: https://git.openjdk.org/jdk/pull/20246/files
Webrev: https://webrevs.openjdk.org/?repo=jdk=20246=00
Issue: https://bugs.openjdk.org/browse/JDK-8334145
Stats: 1 line in 1 file changed: 0 ins;
On Thu, 18 Jul 2024 15:00:41 GMT, Daniel Lundén wrote:
> We are seeing quite a few timeouts for
> `serviceability/sa/ClhsdbDumpheap.java` running with -Xcomp in testing,
> possibly related to
> [JDK-8324241](https://bugs.openjdk.org/browse/JDK-8324241). We should disable
> running
On Thu, 18 Jul 2024 15:00:41 GMT, Daniel Lundén wrote:
> We are seeing quite a few timeouts for
> `serviceability/sa/ClhsdbDumpheap.java` running with -Xcomp in testing,
> possibly related to
> [JDK-8324241](https://bugs.openjdk.org/browse/JDK-8324241). We should disable
> running
The test is failing with an ObjectCollectedException. The test hits a
SUSPEND_ALL breakpoint. It then uses JDI to allocate an Object on the debuggee
side:
testedObject = testedClass.newInstance(thread, ctor, params, 0);
Since we are under a SUSPEND_ALL, the object is not initially
On Thu, 18 Jul 2024 15:00:41 GMT, Daniel Lundén wrote:
> We are seeing quite a few timeouts for
> `serviceability/sa/ClhsdbDumpheap.java` running with -Xcomp in testing,
> possibly related to
> [JDK-8324241](https://bugs.openjdk.org/browse/JDK-8324241). We should disable
> running
On Thu, 18 Jul 2024 05:37:31 GMT, David Holmes wrote:
>> Hi all,
>> The testcase `serviceability/attach/LongArgTest.java` intermittent fails
>> `java.lang.NoClassDefFoundError: jdk/test/lib/Utils`. Jtreg doesn't
>> automatically compile `jdk/test/lib/Utils.class` and
>>
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/SetFieldModificationWa
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/SetFieldModificationWa
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
On Mon, 15 Jul 2024 19:56:13 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 Tue, 9 Jul 2024 04:43:59 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
On Mon, 15 Jul 2024 18:08:26 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
for. So in order to allow the vm.resume() but not subvert the intent of the
> test, we first do a thread2.suspend() so the vm.resume() won't resume thread2.
>
> Testing in progress: tier1 and tier5 svc testing
Chris Plummer has updated the pull request incrementally with one additional
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 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 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 02:44:28 GMT, David Holmes wrote:
>> Chris Plummer has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix copyright and jcheck error
>
> test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadR
for. So in order to allow the vm.resume() but not subvert the intent of the
> test, we first do a thread2.suspend() so the vm.resume() won't resume thread2.
>
> Testing in progress: tier1 and tier5 svc testing
Chris Plummer has updated the pull request incrementally with one additional
On Thu, 11 Jul 2024 15:38:29 GMT, Kevin Walls wrote:
>> Follow-on from JDK-8207908.
>>
>> Two tests are broken by that change:
>> sun/management/jmxremote/startstop/JMXStartStopTest.java
>> sun/management/jmxremote/startstop/JMXStatusPerfCountersTest.java
>>
>> These are additional tests
On Thu, 11 Jul 2024 14:09:57 GMT, Chris Plummer wrote:
>> Sorry I'm unclear on the different threads involved here. IIUC the
>> vm.suspend comes from the debugger, and the mainthread and thread-2 are both
>> threads in the debuggee, being suspended at different times
for. So in order to allow the vm.resume() but not subvert the intent of the
> test, we first do a thread2.suspend() so the vm.resume() won't resume thread2.
>
> Testing in progress: tier1 and tier5 svc testing
Chris Plummer has updated the pull request incrementally with two additional
c
On Thu, 11 Jul 2024 14:51:18 GMT, Kevin Walls wrote:
> Follow-on from JDK-8207908.
>
> Two tests are broken by that change:
> sun/management/jmxremote/startstop/JMXStartStopTest.java
> sun/management/jmxremote/startstop/JMXStatusPerfCountersTest.java
>
> These are additional tests which
On Thu, 11 Jul 2024 07:13:17 GMT, David Holmes wrote:
>> Which logging should be removed? Alex suggest the logging between
>> breakpoints 2 and 3, but even that is not enough. There is logging after
>> breakpoint 3, and that happens before the vm.resume() is done. I'm not
>> saying this can't
On Thu, 11 Jul 2024 01:57:33 GMT, David Holmes wrote:
>> I believe we've done quite a few short sleeps like this in the past. Scaling
>> is not really an issue. It should only require at most a few ms, even with
>> -Xcomp, so we wait 1000ms and then never have to think about the timing
>>
On Wed, 10 Jul 2024 22:29:08 GMT, Daniel D. Daugherty
wrote:
>> Removing log() statements to fix the problem can be risky because someone
>> could re-add them in the future. What about my idea of doing a short sleep
>> before the vm.suspend() to make sure the main thread has advanced to the
On Wed, 10 Jul 2024 20:56:17 GMT, Alex Menkov wrote:
>> I was able to add synchronization between the debugger and debuggee to fix
>> this issue, but I don't really like the solution. It just adds more
>> complexity and makes the test even harder to follow. What I'd like to do is
>> just put
On Wed, 10 Jul 2024 17:10:46 GMT, Chris Plummer wrote:
>>> This does not look correct to me.
>>> This is the last test scenario - thread2.resume should resumes the thread
>>> while vm is suspended.
>>> thread2 should not be blocked on main thread.
&
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 Thu, 4 Jul 2024 14:39:50 GMT, Kevin Walls wrote:
> Test failure, reproducible running batches of tests at the same time on the
> same machine.
> The use of "jcmd TestApp ..." gathers more output than the test wants and
> than its regexes can handle.
>
> Using the PID to match only the
On Wed, 10 Jul 2024 06:46:56 GMT, Chris Plummer wrote:
>> test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/resume/resume001.java
>> line 356:
>>
>>> 354: }
>>> 355:
>>> 356: // We need to resume the main
On Tue, 9 Jul 2024 19:17:26 GMT, Alex Menkov wrote:
> This does not look correct to me.
> This is the last test scenario - thread2.resume should resumes the thread
> while vm is suspended.
> thread2 should not be blocked on main thread.
> Looking at the debuggee I suppose the blocking is
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
eventSet.resume(), which decrements the thread2 suspendCount to 1, so now
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 Wed, 3 Jul 2024 08:24:43 GMT, Kevin Walls wrote:
> Clean backport to jdk23 of a simple test update, to try and avoid spurious
> failures.
Looks good.
-
Marked as reviewed by cjplummer (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/1#pullrequestreview-2164031769
On Mon, 8 Jul 2024 12:16:51 GMT, KIRIYAMA Takuya wrote:
>> This bug was introduced by JDK-8284161. "Object.wait (long timeoutMillis)"
>> was changed to call "Object.wait0 (long timeoutMillis)" in JDK-8284161.
>>
>> When "jhdsb jstack" is executed, the stack and lock information are printed
>>
On Fri, 28 Jun 2024 17:49:10 GMT, Chris Plummer wrote:
> On macosx-aarch64, sometimes the generated core file does not contain all
> valid memory. This causes SA tests to fail with various address related java
> exceptions. There's nothing SA can do to work around th
On Mon, 1 Jul 2024 08:16:07 GMT, Chris Plummer wrote:
>> On macosx-aarch64, sometimes the generated core file does not contain all
>> valid memory. This causes SA tests to fail with various address related java
>> exceptions. There's nothing SA can do to work
On Mon, 1 Jul 2024 17:10:44 GMT, Chris Plummer wrote:
> Clean backport. Need to backport this since it was introduced with the new
> test in [JDK-8333542](https://bugs.openjdk.org/browse/JDK-8333542), which has
> also been backpoted to 23.
This pull request has now been integrated.
On Mon, 1 Jul 2024 17:10:44 GMT, Chris Plummer wrote:
> Clean backport. Need to backport this since it was introduced with the new
> test in [JDK-8333542](https://bugs.openjdk.org/browse/JDK-8333542), which has
> also been backpoted to 23.
Thanks David!
Integrating now sinc
On Mon, 1 Jul 2024 09:31:12 GMT, Kevin Walls wrote:
>> The completely unrelated fix to
>> [JDK-8335124](https://bugs.openjdk.org/browse/JDK-8335124) led me to believe
>> that the issue with sometimes not being able to get the stack trace of the
>> SteadyStateThread might be due to the thread
Clean backport. Need to backport this since it was introduced with the new test
in [JDK-8333542](https://bugs.openjdk.org/browse/JDK-8333542), which has also
been backpoted to 23.
-
Commit messages:
- Backport 4e8cbf884ab1eee9c3110712ab62edc706e948ba
Changes:
t; unfortunately this means no more core file testing on macosx, at least for
> now.
>
> Tested with tier1 and running all tier2 and tier5 SA test tasks.
Chris Plummer has updated the pull request incrementally with one additional
commit since the last revision:
Use proper CR in
Once the main thread has detected that the spawned thread is in the BLOCKED
state, the spawned thread's LingeredAppWithLock.lockMethod() should be visible
on the top of the stack, but it is not, so the "waiting to lock" message is
missing from the stack trace.
I think the explanations
On Fri, 28 Jun 2024 12:14:55 GMT, Coleen Phillimore wrote:
> Clean backport of JDK-8333542. After this, we need a backport for
> JDK-8335134 to fix the test.
Marked as reviewed by cjplummer (Reviewer).
-
PR Review:
The completely unrelated fix to
[JDK-8335124](https://bugs.openjdk.org/browse/JDK-8335124) led me to believe
that the issue with sometimes not being able to get the stack trace of the
SteadyStateThread might be due to the thread being active for a short period
after being reported as in the
On Fri, 28 Jun 2024 18:14:59 GMT, Kevin Walls wrote:
>> Disable running this test with -Xcomp.
>>
>> The NPE seen in this test is due to a timeout establishing the connection.
>> ServerCommunicatorAdmin hits its timeout, during an addNotificationListener
>> call on a new connection.
>>
>>
On macosx-aarch64, sometimes the generated core file does not contain all valid
memory. This causes SA tests to fail with various address related java
exceptions. There's nothing SA can do to work around the problem, and these
failures over time have been just too noisy, so I'm problem listing
On Thu, 27 Jun 2024 08:54:16 GMT, Kevin Walls wrote:
> This test has had occasional failures for years, possibly forever.
> A previous update made the test "othervm" which removed some interruptions,
> but a time accounting problem remains.
>
> This change adds a simple sleep after observing
On Thu, 27 Jun 2024 15:53:09 GMT, Kevin Walls wrote:
> Disable running this test with -Xcomp.
>
> The NPE seen in this test is due to a timeout establishing the connection.
> ServerCommunicatorAdmin hits its timeout, during an addNotificationListener
> call on a new connection.
>
> -Xcomp
On Wed, 26 Jun 2024 17:26:52 GMT, Chris Plummer wrote:
> Allow ObjectCollectedException during ThreadReference.toString() call. This
> can happen when using SUSPEND_NONE since the thread continues to run after
> hitting the breakpoint.
>
> So far I've just run the test lo
On Wed, 26 Jun 2024 17:26:52 GMT, Chris Plummer wrote:
> Allow ObjectCollectedException during ThreadReference.toString() call. This
> can happen when using SUSPEND_NONE since the thread continues to run after
> hitting the breakpoint.
>
> So far I've just run the test lo
On Wed, 26 Jun 2024 06:36:05 GMT, SendaoYan wrote:
> Hi all,
> The newly added test `com/sun/jdi/BreakpointOnClassPrepare.java` fails at
> `SUSPEND_NONE` mode.
> To make this test less noisy, should we disable the SUSPEND_NONE mode for now.
We've done a lot of G1 testing without seeing this
Allow ObjectCollectedException during ThreadReference.toString() call. This can
happen when using SUSPEND_NONE since the thread continues to run after hitting
the breakpoint.
So far I've just run the test locally. I'll run the full suite of debugger
tests before committing. Note I don't know
On Wed, 26 Jun 2024 06:36:05 GMT, SendaoYan wrote:
> Hi all,
> The newly added test `com/sun/jdi/BreakpointOnClassPrepare.java` fails at
> `SUSPEND_NONE` mode.
> To make this test less noisy, should we disable the SUSPEND_NONE mode for now.
@sendaoYan I have a PR out to fix the issue. I think
On Fri, 17 May 2024 19:32:31 GMT, Chris Plummer wrote:
>> This PR adds ranked monitor support to the debug agent. The debug agent has
>> a large number of monitors, and it's really hard to know which order to grab
>> them in, and for that matter which monitors might alre
]
The debug agent should attempt to free vthread ThreadNodes
<https://bugs.openjdk.org/browse/JDK-8282441>. Chris Plummer, you seem
to be assigned to this ticket, is it something that you're working on
or that you'd want to work on, or would you be OK if I took it ?
I'd need som
On Mon, 17 Jun 2024 17:18:01 GMT, Leonid Mesnik wrote:
>> The vmTestbase/vm/share is a shared test library for vmTestbase tests. This
>> library contains a lot of code that is used by only by small number of tests
>> or not used at all. There are no plans to actively develop new tests in
>>
On Thu, 13 Jun 2024 16:55:15 GMT, Sonia Zaldana Calles
wrote:
> Hi all,
>
> This PR addresses [8334164](https://bugs.openjdk.org/browse/JDK-8334164).
>
> Testing:
> - [x] Verified specifying the literal `vm_memory_map_.txt` as the map
> name does not replace ``.
> - [x] Verified `` is
On Fri, 14 Jun 2024 20:18:10 GMT, Leonid Mesnik wrote:
>> The vmTestbase/vm/share is a shared test library for vmTestbase tests. This
>> library contains a lot of code that is used by only by small number of tests
>> or not used at all. There are no plans to actively develop new tests in
>>
On Fri, 14 Jun 2024 23:37:48 GMT, Leonid Mesnik wrote:
>> The nsk jdi,jdb,jdwp test suites support remote and manual launchers that
>> are not used.
>> These launchers might be configured by test options, however no tests use
>> these options.
>> The remote launchers allow to run debugee on
On Fri, 14 Jun 2024 23:05:50 GMT, Leonid Mesnik wrote:
>> The nsk jdi,jdb,jdwp test suites support remote and manual launchers that
>> are not used.
>> These launchers might be configured by test options, however no tests use
>> these options.
>> The remote launchers allow to run debugee on
On Fri, 14 Jun 2024 16:37:15 GMT, Leonid Mesnik wrote:
> The vmTestbase/vm/share is a shared test library for vmTestbase tests. This
> library contains a lot of code that is used by only by small number of tests
> or not used at all. There are no plans to actively develop new tests in
>
On Fri, 14 Jun 2024 03:51:28 GMT, Leonid Mesnik wrote:
>> The nsk.share.Log has 3 parameters that might be configured by tests or
>> using command-line:
>> - verbose, traceLevel and timestamp
>>
>> The main purpose of these modes was to minimize output and use command-line
>> arguments to
On Fri, 14 Jun 2024 00:49:28 GMT, Leonid Mesnik wrote:
>> The nsk.share.Log has 3 parameters that might be configured by tests or
>> using command-line:
>> - verbose, traceLevel and timestamp
>>
>> The main purpose of these modes was to minimize output and use command-line
>> arguments to
On Fri, 14 Jun 2024 00:03:32 GMT, Leonid Mesnik wrote:
>> test/hotspot/jtreg/vmTestbase/nsk/share/Log.java line 130:
>>
>>> 128: * Default value is 0 a.k.a.
>>> TraceLevel.INFO;
>>> 129: */
>>> 130: private final int traceLevel = TraceLevel.TRACE_DEBUG + 1;
>>
>> Can you explain
On Tue, 11 Jun 2024 07:45:29 GMT, Kevin Walls wrote:
>> src/hotspot/share/services/diagnosticCommand.cpp line 1211:
>>
>>> 1209: } else {
>>> 1210: name = _filename.value();
>>> 1211: }
>>
>> This code should be considering if a default it specified or not, in case
>> the specified
On Tue, 11 Jun 2024 18:11:55 GMT, Kevin Walls wrote:
>> jstatd is an RMI server application which monitors HotSpot VMs, and provides
>> an interface to the monitoring tool jstat, for use across a remote RMI
>> connection.
>>
>> RMI is not how modern applications communicate. It is an old
On Tue, 11 Jun 2024 18:48:41 GMT, Leonid Mesnik wrote:
>> The jdwp tests use debugger and debugee. There is no goal to execute
>> debugger part with all VM flags, they are needed to be used with debugee VM
>> only.
>> The change is all tests is to don't use System.exit() and use 'driver'
>>
On Mon, 10 Jun 2024 21:58:29 GMT, Damon Nguyen wrote:
>> This issue is responsible for updating the translations of all the
>> localize(able) resources in the JDK. Primarily, the changes between JDK 22
>> RDP 1 and the integration of the JDK 23 RDP 1 L10n drop will be translated.
>>
>> The
On Tue, 11 Jun 2024 13:00:44 GMT, Matthias Baesken wrote:
> When running HS :tier1 tests with ubsan-enabled binaries, the following issue
> is reported :
> test
> serviceability/jvmti/FollowReferences/FieldIndices/FieldIndicesTest.jtr
>
>
On Sun, 5 May 2024 18:07:47 GMT, Leonid Mesnik wrote:
>> The jdwp tests use debugger and debugee. There is no goal to execute
>> debugger part with all VM flags, they are needed to be used with debugee VM
>> only.
>> The change is all tests is to don't use System.exit() and use 'driver'
>>
On Tue, 11 Jun 2024 11:34:34 GMT, Serguei Spitsyn wrote:
> Please, review a jdk23 backport of the:
> [8333931](https://bugs.openjdk.org/browse/JDK-8333931): Problemlist
> serviceability/jvmti/vthread/CarrierThreadEventNotification
>
> Thanks
Marked as reviewed by cjplummer (Reviewer).
On Tue, 11 Jun 2024 02:10:46 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this test-only change which fixes an issue that
>> was introduced due to the refactoring that we did in
>> https://bugs.openjdk.org/browse/JDK-8333130? This PR addresses the failure
>> reported in
On Mon, 10 Jun 2024 21:58:29 GMT, Damon Nguyen wrote:
>> This issue is responsible for updating the translations of all the
>> localize(able) resources in the JDK. Primarily, the changes between JDK 22
>> RDP 1 and the integration of the JDK 23 RDP 1 L10n drop will be translated.
>>
>> The
On Fri, 7 Jun 2024 10:31:22 GMT, Jaikiran Pai wrote:
> Can I please get a review of this test-only change which fixes an issue that
> was introduced due to the refactoring that we did in
> https://bugs.openjdk.org/browse/JDK-8333130? This PR addresses the failure
> reported in
On Sat, 8 Jun 2024 17:00:04 GMT, Leonid Mesnik wrote:
> Tests
> SetFieldAccessWatch/setfldw001
> SetFieldModificationWatch/setfmodw001
> intermittently fail with Xcomp. I was unable to reproduce the problem.
> The fix adds more checks and variants with jvmti logging.
>
> The goal is to
On Fri, 7 Jun 2024 10:40:07 GMT, Thomas Stuefe wrote:
> @dholmes-ora this is one of yours.
>
> This was a tad annoying to fix (fix is simple though), since the jcmd
> framework has no good way to allow for default parameters that are not used
> literally. E.g. in this case, the real value for
On Fri, 7 Jun 2024 19:56:03 GMT, Chris Plummer wrote:
> Allow warning messages such as the following to appear in stderr:
>
> Java HotSpot(TM) 64-Bit Server VM warning: Temporarily processing option
> UseNotificationThread; support is scheduled for removal in 24.0
>
> Te
1 - 100 of 1576 matches
Mail list logo
