On Thu, 30 Jan 2025 10:22:17 GMT, Matthias Baesken wrote:
> We should the exception message from
> Caused by: java.lang.RuntimeException: No type named
> "DeoptimizeObjectsALotThread" in database
> to
> Caused by: java.lang.RuntimeException: No type named
> "DeoptimizeObjectsALotThread" present
On 1/21/25 12:57 PM, some-java-user-99206970363698485...@vodafonemail.de
wrote:
It seems I wasn't informed that the report had been created; at
least I cannot find the confirmation mail for it. Note that I had
specified a different private contact e-mail address.
It's because the bug isn't
On Wed, 29 Jan 2025 12:46:29 GMT, Matthias Baesken wrote:
>> We were running into this error :
>> sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java on Linux aarch64, jdk25
>>
>> stderr: [java.lang.RuntimeException: Unable to deduce type of thread from
>> address 0x34144e30 (expected ty
On Tue, 28 Jan 2025 14:08:26 GMT, Serguei Spitsyn wrote:
>> Some `nsk.jvmti` tests are failed with the `-testThreadFactory:Virtual`, so
>> they are listed in the `test/hotspot/jtreg/ProblemList-Virtual.txt`.
>>
>> The fix is to adjust tests expectations regarding tested virtual threads to
>> e
On Thu, 23 Jan 2025 09:07:23 GMT, Matthias Baesken wrote:
>> We were running into this error :
>> sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java on Linux aarch64, jdk25
>>
>> stderr: [java.lang.RuntimeException: Unable to deduce type of thread from
>> address 0x34144e30 (expected ty
On Tue, 28 Jan 2025 19:14:56 GMT, Chris Plummer wrote:
> DeoptimizeObjectsALotThread was being unconditionally added to the mapping
> table:
>
>virtualConstructor.addMapping("DeoptimizeObjectsALotThread",
> DeoptimizeObjectsALotThread.class);
>
> B
On Tue, 28 Jan 2025 20:14:05 GMT, Chris Plummer wrote:
>> DeoptimizeObjectsALotThread was being unconditionally added to the mapping
>> table:
>>
>>virtualConstructor.addMapping("DeoptimizeObjectsALotThread",
>> DeoptimizeObjectsALotThread.clas
On Tue, 28 Jan 2025 19:42:57 GMT, Aleksey Shipilev wrote:
>> Chris Plummer has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> use lookupType() api that does not throw an exception.
>
> src/jdk.hotspot.agent
y with a debug build using
> TEST_VM_OPTS=-XX:+DeoptimizeObjectsALot to make sure the original
> DeoptimizeObjectsALotThread issue is still fixed, and then tested a release
> build without TEST_VM_OPTS=-XX:+DeoptimizeObjectsALot to make sure this new
> issue did not reproduce.
C
DeoptimizeObjectsALotThread was being unconditionally added to the mapping
table:
virtualConstructor.addMapping("DeoptimizeObjectsALotThread",
DeoptimizeObjectsALotThread.class);
But is conditionally included in VMStructs:
DEBUG_ONLY(COMPILER2_OR_JVMCI_PRESENT( \
decl
On Mon, 27 Jan 2025 11:24:33 GMT, Serguei Spitsyn wrote:
> Some `nsk.jvmti` tests are failed with the `-testThreadFactory:Virtual`, so
> they are listed in the `test/hotspot/jtreg/ProblemList-Virtual.txt`.
>
> The fix is to adjust tests expectations regarding tested virtual threads to
> expect
On Sun, 26 Jan 2025 20:27:32 GMT, Kevin Walls wrote:
>> The System Property "jmx.invoke.getters" was added in
>> [JDK-4949203](https://bugs.openjdk.org/browse/JDK-4949203) to optionally be
>> compatible with a time before JDK-6, when calling invoke on getters and
>> setters was permitted.
>>
On Thu, 23 Jan 2025 20:15:35 GMT, Chris Plummer wrote:
> If you run hotspot with -XX:+DeoptimizeObjectsALot, it will create one or
> more DeoptimizeObjectsALotThread threads. This is one of many JavaThread
> subclasses that SA needs to know about, but in this case it does not. When SA
On Fri, 24 Jan 2025 20:22:07 GMT, Chris Plummer wrote:
>> If you run hotspot with -XX:+DeoptimizeObjectsALot, it will create one or
>> more DeoptimizeObjectsALotThread threads. This is one of many JavaThread
>> subclasses that SA needs to know about, but in this case it doe
added a new
> ClearAllFramePops() API to allow clearing of the NotifyFramePop() and normal
> performance to resume.
>
> Testing:
>
> - [x] Tier1 CI
> - [x] Tier2 CI svc testing
> - [x] Tier3 CI svc testing
> - [x] Tier5 CI svc testing
> - [x] ran all svc test 10 times each on
On Fri, 24 Jan 2025 22:52:19 GMT, Dean Long wrote:
> > > Overall the changes seem fine, however it would be nice if the
> > > vmStructs.cpp registration mechanism was modular and extensible, instead
> > > of monolithic. That would make it easier to register private types, or
> > > even types o
On Fri, 24 Jan 2025 11:55:23 GMT, Kevin Walls wrote:
>> The System Property "jmx.invoke.getters" was added in
>> [JDK-4949203](https://bugs.openjdk.org/browse/JDK-4949203) to optionally be
>> compatible with a time before JDK-6, when calling invoke on getters and
>> setters was permitted.
>>
On Fri, 24 Jan 2025 20:13:29 GMT, Chris Plummer wrote:
>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Threads.java
>> line 168:
>>
>>> 166: JvmtiAgentThread, NotificationThread, MonitorDeflationThread,
>>> 167: Str
ests will fail:
>
> make test TEST=serviceability/sa TEST_VM_OPTS=-XX:+DeoptimizeObjectsALot
>
> I had to move the native DeoptimizeObjectsALotThread declaration to
> compileBroker.hpp to make it visible to vmStructs.cpp.
>
> I tested with the above "make test" c
On Fri, 24 Jan 2025 11:52:04 GMT, Serguei Spitsyn wrote:
>> Chris Plummer has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Some minor cleanup.
>
> src/jdk.jdwp.agent/share/native/libjdwp/stepControl.
On Fri, 24 Jan 2025 10:19:30 GMT, Kevin Walls wrote:
>> If you run hotspot with -XX:+DeoptimizeObjectsALot, it will create one or
>> more DeoptimizeObjectsALotThread threads. This is one of many JavaThread
>> subclasses that SA needs to know about, but in this case it does not. When
>> SA trie
added a new
> ClearAllFramePops() API to allow clearing of the NotifyFramePop() and normal
> performance to resume.
>
> Testing:
>
> - [x] Tier1 CI
> - [x] Tier2 CI svc testing
> - [x] Tier3 CI svc testing
> - [x] Tier5 CI svc testing
> - [x] ran all svc test 10 times each on
On Fri, 24 Jan 2025 20:03:12 GMT, Chris Plummer wrote:
>> It's gone. Are you sure you are looking at the latest sources?
>
> Hmm. Now it looks like it is there.
I see now. I got rid one for resuming but not the one for suspending. It should
be gone now.
-
PR Revi
On Fri, 24 Jan 2025 20:02:23 GMT, Chris Plummer wrote:
>> src/jdk.jdwp.agent/share/native/libjdwp/stepControl.c line 913:
>>
>>> 911:
>>> 912: if (needsSuspending) {
>>> 913: tty_message("clearStep: suspending thread");
>&
On Thu, 23 Jan 2025 22:03:45 GMT, Dean Long wrote:
> Overall the changes seem fine, however it would be nice if the vmStructs.cpp
> registration mechanism was modular and extensible, instead of monolithic.
> That would make it easier to register private types, or even types outside of
> libjvm
If you run hotspot with -XX:+DeoptimizeObjectsALot, it will create one or more
DeoptimizeObjectsALotThread threads. This is one of many JavaThread subclasses
that SA needs to know about, but in this case it does not. When SA tries to
create a mirror of one of these threads, it fails with:
std
On Wed, 22 Jan 2025 07:27:48 GMT, Serguei Spitsyn wrote:
>> Chris Plummer has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Some minor cleanup.
>
> src/jdk.jdwp.agent/share/native/libjdwp/stepControl.
added a new
> ClearAllFramePops() API to allow clearing of the NotifyFramePop() and normal
> performance to resume.
>
> Testing:
>
> - [x] Tier1 CI
> - [x] Tier2 CI svc testing
> - [x] Tier3 CI svc testing
> - [x] Tier5 CI svc testing
> - [x] ran all svc test 10 times each on
On Wed, 22 Jan 2025 08:49:52 GMT, Matthias Baesken wrote:
>> test/jdk/sun/tools/jhsdb/JShellHeapDumpTest.java line 104:
>>
>>> 102: if (!res) { // try once more
>>> 103: launch(expectedMessage, Arrays.asList(toolArgs), false);
>>> 104: }
>>
>> `launch()` should take
On Tue, 21 Jan 2025 13:24:41 GMT, Matthias Baesken wrote:
> We were running into this error :
> sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java on Linux aarch64, jdk25
>
> stderr: [java.lang.RuntimeException: Unable to deduce type of thread from
> address 0x34144e30 (expected type Ja
When doing a STEP_OVER, the debug agent does a NotifyFramePop() on the current
frame as a safety net. After the STEP_OVER completes, the NotifyFramePop() is
usually still in place. This keeps the thread in interp_only mode, which hurts
performance. JVMTI has added a new ClearAllFramePops() API
On Fri, 17 Jan 2025 02:09:54 GMT, Serguei Spitsyn wrote:
>> The test lacks a synchronization, so it is added by this fix.
>>
>> Testing:
>> - Ran the failing test `vmTestbase/nsk/jvmti/GetThreadCpuTime/thrcputime002`
>> - TBD: submit mach5 tiers 1-5
>
> Serguei Spitsyn has updated the pull req
On Thu, 16 Jan 2025 09:15:28 GMT, Serguei Spitsyn wrote:
> The test lacks a synchronization, so it is added by this fix.
>
> Testing:
> - Ran the failing test `vmTestbase/nsk/jvmti/GetThreadCpuTime/thrcputime002`
> - TBD: submit mach5 tiers 1-5
test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetThrea
On Thu, 16 Jan 2025 12:20:14 GMT, Kevin Walls wrote:
> Classes should not override
> javax.management.openmbean.OpenType.getClassName(), and this was made illegal
> (caused an Exception) in JDK6. A System Property jmx.extend.open.types was
> introduced to allow such an override, for compatibi
On Thu, 16 Jan 2025 13:05:58 GMT, Kevin Walls wrote:
> Remove the System Property "jmx.tabular.data.hash.map" which was introduced
> historically for JMX compatibility with JDK 1.3 clients.
Marked as reviewed by cjplummer (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/2
On Wed, 15 Jan 2025 08:23:57 GMT, SendaoYan wrote:
> Hi all,
> We observed the test serviceability/sa/TestJhsdbJstackMixed.java intermittent
> fails on linux-riscv64. Should we problemlist this test before the root cause
> has been fixed.
Although it's up to the riskv64 maintainers to decide i
On Sat, 11 Jan 2025 06:01:33 GMT, Serguei Spitsyn wrote:
>> This is a fix of one more deadlock issue related to `interruptLock` critical
>> sections. When the `interruptLock` is hold by the target virtual thread it
>> is unsafe to suspend or post JVMTI events. This update is to ignore the
>> J
On Fri, 10 Jan 2025 02:27:16 GMT, Serguei Spitsyn wrote:
>> This is a fix of one more deadlock issue related to `interruptLock` critical
>> sections. When the `interruptLock` is hold by the target virtual thread it
>> is unsafe to suspend or post JVMTI events. This update is to ignore the
>> J
On Thu, 9 Jan 2025 15:13:01 GMT, Matthias Baesken wrote:
> When running ubsan-enabled binaries on macOS aarch64, in test
> javax/management/MBeanServer/OldMBeanServerTest.java
> the following division by zero is shown :
> src/jdk.management/macosx/native/libmanagement_ext/UnixOperatingSystem.c:67
On Thu, 9 Jan 2025 05:03:33 GMT, Serguei Spitsyn wrote:
> This is a fix of one more deadlock issue related to `interruptLock` critical
> sections. When the `interruptLock` is hold by the target virtual thread it is
> unsafe to suspend or post JVMTI events. This update is to ignore the JVMTI
>
On Wed, 8 Jan 2025 05:23:29 GMT, Chris Plummer wrote:
> Since [JDK-8285417](https://bugs.openjdk.org/browse/JDK-8285417) is now
> closed as a dup of
> [JDK-8347137](https://bugs.openjdk.org/browse/JDK-8347137), its problem list
> entry needs to be updated.
This pull request
On Wed, 8 Jan 2025 05:23:29 GMT, Chris Plummer wrote:
> Since [JDK-8285417](https://bugs.openjdk.org/browse/JDK-8285417) is now
> closed as a dup of
> [JDK-8347137](https://bugs.openjdk.org/browse/JDK-8347137), its problem list
> entry needs to be updated.
Thank you Al
On Tue, 7 Jan 2025 19:47:10 GMT, Serguei Spitsyn wrote:
>> The JVMTI NotifyFramePop should return JVMTI_ERROR_DUPLICATE in a case the
>> specified FramePop event was already requested. This makes it consistent
>> with the SetBreakpoint which returns the JVMTI_ERROR_DUPLICATE on an attempt
>> t
On Tue, 7 Jan 2025 19:53:20 GMT, Serguei Spitsyn wrote:
>> New JVMTI function `ClearAllFramePops` will help to speedup debugger single
>> stepping in some cases.
>> Additionally, the JVMTI `NotifyFramePop` implementation was fixed to return
>> `JVMTI_ERROR_DUPLICATE` to make it consistent with
Since [JDK-8285417](https://bugs.openjdk.org/browse/JDK-8285417) is now closed
as a dup of [JDK-8347137](https://bugs.openjdk.org/browse/JDK-8347137), its
problem list entry needs to be updated.
-
Commit messages:
- Update CR for VMOutOfMemoryException problem list entry
Changes:
On Fri, 20 Dec 2024 01:23:22 GMT, Serguei Spitsyn wrote:
>> The JVMTI NotifyFramePop should return JVMTI_ERROR_DUPLICATE in a case the
>> specified FramePop event was already requested. This makes it consistent
>> with the SetBreakpoint which returns the JVMTI_ERROR_DUPLICATE on an attempt
>>
On Thu, 19 Dec 2024 05:24:20 GMT, Serguei Spitsyn wrote:
>> New JVMTI function `ClearAllFramePops` will help to speedup debugger single
>> stepping in some cases.
>> Additionally, the JVMTI `NotifyFramePop` implementation was fixed to return
>> `JVMTI_ERROR_DUPLICATE` to make it consistent with
On Thu, 19 Dec 2024 04:46:12 GMT, Serguei Spitsyn wrote:
>> The JVMTI NotifyFramePop should return JVMTI_ERROR_DUPLICATE in a case the
>> specified FramePop event was already requested. This makes it consistent
>> with the SetBreakpoint which returns the JVMTI_ERROR_DUPLICATE on an attempt
>>
On Wed, 18 Dec 2024 03:12:14 GMT, Serguei Spitsyn wrote:
>> The JVMTI NotifyFramePop should return JVMTI_ERROR_DUPLICATE in a case the
>> specified FramePop event was already requested. This makes it consistent
>> with the SetBreakpoint which returns the JVMTI_ERROR_DUPLICATE on an attempt
>>
On Tue, 17 Dec 2024 21:01:51 GMT, Serguei Spitsyn wrote:
> The JVMTI NotifyFramePop should return JVMTI_ERROR_DUPLICATE in a case the
> specified FramePop event was already requested. This makes it consistent with
> the SetBreakpoint which returns the JVMTI_ERROR_DUPLICATE on an attempt to
> a
On Tue, 17 Dec 2024 17:35:52 GMT, Serguei Spitsyn wrote:
>> src/hotspot/share/interpreter/interpreterRuntime.cpp line 580:
>>
>>> 578: // notify debugger of an exception catch
>>> 579: // (this is good for exceptions caught in native methods as well)
>>> 580: if (JvmtiExport::can_post_on_e
On Wed, 11 Dec 2024 17:39:14 GMT, Chris Plummer wrote:
>> This test fails after
>> [JDK-8338713](https://bugs.openjdk.org/browse/JDK-8338713) when using
>> JTREG_TEST_THREAD_FACTORY=Virtual. The test uses JVMTI StopThread on a
>> thread expecting it to be mounted.
On Fri, 6 Dec 2024 22:28:29 GMT, Chris Plummer wrote:
> This test fails after
> [JDK-8338713](https://bugs.openjdk.org/browse/JDK-8338713) when using
> JTREG_TEST_THREAD_FACTORY=Virtual. The test uses JVMTI StopThread on a thread
> expecting it to be mounted. Before
> [JDK
On Mon, 16 Dec 2024 23:25:49 GMT, Serguei Spitsyn wrote:
>> New JVMTI function `ClearAllFramePops` will help to speedup debugger single
>> stepping in some cases.
>> Additionally, the JVMTI `NotifyFramePop` implementation was fixed to return
>> `JVMTI_ERROR_DUPLICATE` to make it consistent with
On Tue, 17 Dec 2024 01:59:52 GMT, David Holmes wrote:
>> test/hotspot/jtreg/vmTestbase/nsk/share/jdb/Launcher.java line 142:
>>
>>> 140: /* Some jdb tests need java.library.path setup for native
>>> libraries. */
>>> 141: String libpath = System.getProperty("java.library
On Mon, 16 Dec 2024 20:33:22 GMT, Coleen Phillimore wrote:
> Please review this trivial change to remove unused SA code. Ran
> serviceability/sa tests, tier1 testing in progress.
Looks good.
-
Marked as reviewed by cjplummer (Reviewer).
PR Review: https://git.openjdk.org/jdk/pul
On Fri, 13 Dec 2024 20:50:37 GMT, Serguei Spitsyn wrote:
> New JVMTI function `ClearAllFramePops` will help to speedup debugger single
> stepping in some cases.
> Additionally, the JVMTI `NotifyFramePop` implementation was fixed to return
> `JVMTI_ERROR_DUPLICATE` to make it consistent with the
On Wed, 11 Dec 2024 17:39:14 GMT, Chris Plummer wrote:
>> This test fails after
>> [JDK-8338713](https://bugs.openjdk.org/browse/JDK-8338713) when using
>> JTREG_TEST_THREAD_FACTORY=Virtual. The test uses JVMTI StopThread on a
>> thread expecting it to be mounted.
On Mon, 16 Dec 2024 11:11:20 GMT, Kevin Walls wrote:
> Simple test update to fix some typos and formatting changes, seen while
> investigating and testing for JDK-8241865.
Marked as reviewed by cjplummer (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/22761#pullrequestre
On Mon, 16 Dec 2024 09:57:33 GMT, Kevin Walls wrote:
> Fairly frequent failures on macosx-aarch64. For a while it was always on
> 15.0.1, but now also seen on "Mac OS X 12.7.1 (aarch64)", so this should be
> problemlisted for macosx-aarch64.
>
> There are existing entries for aix, and the Pro
On Fri, 13 Dec 2024 23:07:53 GMT, Alex Menkov wrote:
>> In some circumstances ClassFileTransformer.transform can get
>> ClassCircularityError or LinkageError concatenating strings (see
>> JDK-8264667, JDK-8262002).
>> VerifyLocalVariableTableOnRetransformTest fails sometimes on Oracle CI.
>> Th
On Fri, 13 Dec 2024 21:51:10 GMT, Alex Menkov wrote:
>> In some circumstances ClassFileTransformer.transform can get
>> ClassCircularityError or LinkageError concatenating strings (see
>> JDK-8264667, JDK-8262002).
>> VerifyLocalVariableTableOnRetransformTest fails sometimes on Oracle CI.
>> Th
On Fri, 13 Dec 2024 02:21:42 GMT, Alex Menkov wrote:
> In some circumstances ClassFileTransformer.transform can get
> ClassCircularityError or LinkageError concatenating strings (see JDK-8264667,
> JDK-8262002).
> VerifyLocalVariableTableOnRetransformTest fails sometimes on Oracle CI.
> The fix
On Fri, 13 Dec 2024 18:58:12 GMT, Kevin Walls wrote:
> This test has been noisy lately, and all the failures have been on "Mac OS X
> 15.0.1 (aarch64)".
>
> Forcing it to require any other OS version looks good in my testing.
test/jdk/sun/management/jdp/JdpDefaultsTest.java line 33:
> 31: *
On Thu, 12 Dec 2024 09:54:03 GMT, Kevin Walls wrote:
>> Unnecessary duplication of small utility method. There should be only one
>> Util.newObjectName().
>
> Kevin Walls has updated the pull request with a new target base due to a
> merge or a rebase. The incremental webrev excludes the unrel
On Wed, 11 Dec 2024 21:15:19 GMT, Kevin Walls wrote:
> Right, there are two Util classes, and some classes use both... e.g.
> ObjectName.java uses com.sun.jmx.mbeanserver.Util (for Util.wildmatch()), and
> I want to use newObjectName from sun.management.Util.
In that case I'd probably just use
On Wed, 11 Dec 2024 13:55:24 GMT, Kevin Walls wrote:
> Unnecessary duplication of small utility method. There should be only one
> Util.newObjectName().
src/java.management/share/classes/javax/management/ObjectName.java line 40:
> 38: import java.util.Map;
> 39:
> 40: import static sun.manag
On Wed, 11 Dec 2024 13:04:51 GMT, Kevin Walls wrote:
>> A post-SecurityManager removal cleanup task, to remove checkAccess(),
>> checkMonitorAccess() and checkControlAccess() from
>> src/java.management/share/classes/sun/management/Util.java (methods are
>> already no-ops).
>>
>> While here,
d platform thread
> mode.
> - [x] tier1
> - [x] tier2 svc
> - [x] tier5 svc
Chris Plummer has updated the pull request incrementally with one additional
commit since the last revision:
Rename run1() to test()
-
Changes:
- all: https://git.openjdk.org/jdk/pull
On Mon, 9 Dec 2024 12:47:29 GMT, Magnus Ihse Bursie wrote:
> Some files have been modified in 2024, but the copyright year has not been
> properly updated. This should be fixed.
>
> I have located these modified files using:
>
> git log --since="Jan 1" --name-only --pretty=format: | sort -u >
On Mon, 9 Dec 2024 21:44:42 GMT, Serguei Spitsyn wrote:
> > I think you and @AlanBateman didn't quite understand what I meant by:
> > . . .
> > The run1() method is called regardless of whether or not we are using
> > vthreads and VThreadPinner, so I don't think runPinned() is a good name for
>
On Mon, 9 Dec 2024 20:52:14 GMT, Serguei Spitsyn wrote:
> The fix looks good modulo potential renaming of the `run1()` method.
I think you and @AlanBateman did quite understand what I meant by:
> It also needs to support test runs with platforms threads. See how run()
> checks if it is running
On Sat, 7 Dec 2024 07:33:07 GMT, Alan Bateman wrote:
>> This test fails after
>> [JDK-8338713](https://bugs.openjdk.org/browse/JDK-8338713) when using
>> JTREG_TEST_THREAD_FACTORY=Virtual. The test uses JVMTI StopThread on a
>> thread expecting it to be mounted. Before
>> [JDK-8338713](https:
This test fails after
[JDK-8338713](https://bugs.openjdk.org/browse/JDK-8338713) when using
JTREG_TEST_THREAD_FACTORY=Virtual. The test uses JVMTI StopThread on a thread
expecting it to be mounted. Before
[JDK-8338713](https://bugs.openjdk.org/browse/JDK-8338713) it would be mounted
because it
On Tue, 3 Dec 2024 20:16:33 GMT, Chris Plummer wrote:
> The root cause of [JDK-8344804](https://bugs.openjdk.org/browse/JDK-8344804)
> seems to be some JNI Checker warnings. I decided to resolve all the warnings
> in the debug agent and debugger tests that start with "in
On Thu, 5 Dec 2024 01:21:26 GMT, Chris Plummer wrote:
>> The root cause of [JDK-8344804](https://bugs.openjdk.org/browse/JDK-8344804)
>> seems to be some JNI Checker warnings. I decided to resolve all the warnings
>> in the debug agent and debugger tests that start with
On Thu, 5 Dec 2024 00:56:25 GMT, Chris Plummer wrote:
>> The root cause of [JDK-8344804](https://bugs.openjdk.org/browse/JDK-8344804)
>> seems to be some JNI Checker warnings. I decided to resolve all the warnings
>> in the debug agent and debugger tests that start with
All tier4, which is where
> [JDK-8344804](https://bugs.openjdk.org/browse/JDK-8344804) reproduced
> - [x] All tier5 svc tests
Chris Plummer has updated the pull request incrementally with one additional
commit since the last revision:
get rid of temporary debugging assert
-
Changes
All tier4, which is where
> [JDK-8344804](https://bugs.openjdk.org/browse/JDK-8344804) reproduced
> - [x] All tier5 svc tests
Chris Plummer has updated the pull request incrementally with one additional
commit since the last revision:
use saveGlobalRefHelper() for invokeNonvirtual()
-
C
On Wed, 4 Dec 2024 23:02:32 GMT, Chris Plummer wrote:
>>> What I'm not so sure of is which JNI functions check this flag (I know only
>>> the "call" functions set it)
>>
>> In `invokeNonVirtual` we calls `CallNonvirtualObjectMethodA` JNI functio
On Wed, 4 Dec 2024 22:56:50 GMT, Alex Menkov wrote:
>> I think there are two types of checks for exceptions; implicit and explicit.
>>
>> For the implicit check, the "call" functions all set a flag saying an
>> exception check is needed. So this will trigger the "in native method"
>> warning o
On Wed, 4 Dec 2024 21:49:05 GMT, Alex Menkov wrote:
>> I don't believe so because if an object is returned then that implies that
>> there was no exception thrown.
>
> It's the same like other calls here (invokeVirtual, etc), so I'd expect it
> produces "in native method" warning.
> Maybe we do
On Wed, 4 Dec 2024 21:12:57 GMT, Alex Menkov wrote:
>> The root cause of [JDK-8344804](https://bugs.openjdk.org/browse/JDK-8344804)
>> seems to be some JNI Checker warnings. I decided to resolve all the warnings
>> in the debug agent and debugger tests that start with "in native method".
>> Th
On Wed, 4 Dec 2024 05:56:35 GMT, Chris Plummer wrote:
>> Sure but when it does fail because of a bug the person trying to debug it
>> will lament the fact they don't know what exception was encountered. Seems a
>> little helper function could do the above and
On Tue, 3 Dec 2024 20:16:33 GMT, Chris Plummer wrote:
> The root cause of [JDK-8344804](https://bugs.openjdk.org/browse/JDK-8344804)
> seems to be some JNI Checker warnings. I decided to resolve all the warnings
> in the debug agent and debugger tests that start with "in
On Wed, 4 Dec 2024 05:38:14 GMT, David Holmes wrote:
>> That might be nice, but we don't do it in other places where we have this
>> pattern. This call should never fail, thus the "fatal error" approach.
>
> Sure but when it does fail because of a bug the person trying to debug it
> will lament
On Wed, 4 Dec 2024 03:07:46 GMT, Alex Menkov wrote:
> The PR fixes race in the test between ThreadStart/ThreadEnd callbacks and
> agent thread:
> The callbacks increments event counter and then do self-suspend;
> Agent thread waits when expected number of events is received, then performs
> ver
On Wed, 4 Dec 2024 02:07:13 GMT, David Holmes wrote:
>> The root cause of [JDK-8344804](https://bugs.openjdk.org/browse/JDK-8344804)
>> seems to be some JNI Checker warnings. I decided to resolve all the warnings
>> in the debug agent and debugger tests that start with "in native method".
>> T
On Mon, 2 Dec 2024 21:49:59 GMT, Chris Plummer wrote:
> The log message is wrong. Copy-n-paste bug from another part of the test.
>
> I'd like to push this as a trivial change.
This pull request has now been integrated.
Changeset: 42378970
Author: Chris Plummer
URL
On Mon, 2 Dec 2024 21:49:59 GMT, Chris Plummer wrote:
> The log message is wrong. Copy-n-paste bug from another part of the test.
>
> I'd like to push this as a trivial change.
Thanks Alex and Leonid!
-
PR Comment: https://git.openjdk.org/jdk/pull/22499#issuecomment-2515851469
On Tue, 3 Dec 2024 20:16:33 GMT, Chris Plummer wrote:
> The root cause of [JDK-8344804](https://bugs.openjdk.org/browse/JDK-8344804)
> seems to be some JNI Checker warnings. I decided to resolve all the warnings
> in the debug agent and debugger tests that start with "in
The root cause of [JDK-8344804](https://bugs.openjdk.org/browse/JDK-8344804)
seems to be some JNI Checker warnings. I decided to resolve all the warnings in
the debug agent and debugger tests that start with "in native method". This
seems to have resolved
[JDK-8344804](https://bugs.openjdk.org/
On Thu, 28 Nov 2024 01:30:58 GMT, Alex Menkov wrote:
> Fix for JDK-8337317 (#20699) updated serviceability/jvmti/HiddenClass and
> serviceability/jvmti/VMObjectAlloc tests adding guards against
> JVMTI_ERROR_WRONG_PHASE errors, but missed to enable JVMTI_EVENT_VM_DEATH
> events.
> This fix add
On Wed, 27 Nov 2024 02:13:41 GMT, Leonid Mesnik wrote:
> The real bug is
> https://bugs.openjdk.org/browse/CODETOOLS-7902847 Class directory of a test
> case should not be used to compile a library
>
> and the following workaround just excludes the testing group where it fails
> often.
>
> T
The log message is wrong. Copy-n-paste bug from another part of the test.
I'd like to push this as a trivial change.
-
Commit messages:
- fix log message
Changes: https://git.openjdk.org/jdk/pull/22499/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22499&range=00
Issue:
On Thu, 21 Nov 2024 21:26:01 GMT, Adam Bruce wrote:
>> This PR fixes a long-standing bug in JDWP where the access flags of a field
>> are not checked before attempting to read it's value.
>>
>> Prior to this change, attempting to read a non-static field would cause a
>> JVM crash, this change
On Thu, 21 Nov 2024 21:26:01 GMT, Adam Bruce wrote:
>> This PR fixes a long-standing bug in JDWP where the access flags of a field
>> are not checked before attempting to read it's value.
>>
>> Prior to this change, attempting to read a non-static field would cause a
>> JVM crash, this change
On Thu, 21 Nov 2024 21:26:01 GMT, Adam Bruce wrote:
>> This PR fixes a long-standing bug in JDWP where the access flags of a field
>> are not checked before attempting to read it's value.
>>
>> Prior to this change, attempting to read a non-static field would cause a
>> JVM crash, this change
On Thu, 21 Nov 2024 19:43:40 GMT, Leonid Mesnik wrote:
>> Hi
>> Could you please review the the fix that add locks information into SA jhsdb
>> stack --mixed output.
>>
>> Here is the motivation for this rfe and explanation why I add it into SA now.
>>
>> The information about current owners o
On Thu, 14 Nov 2024 22:15:29 GMT, Chris Plummer wrote:
> These two tests both do stack dumps with one or more active threads. This can
> result in SA throwing an exception if the thread is in a bad state. However,
> SA will still generate stack traces for all other threads, and
1 - 100 of 1896 matches
Mail list logo
