On Mon, 4 Sep 2023 14:18:55 GMT, Roman Marchenko wrote:
> This change added a simple check in
> test/hotspot/jtreg/serviceability/sa/ClhsdbDumpclass.java if BootstrapMethods
> attribute was dumped. (similar to test changes in PR #14556)
Marked as reviewed by cjplummer (Reviewer).
I think the
On Sat, 2 Sep 2023 00:50:08 GMT, Alex Menkov wrote:
> JDK-8226420 has been closed as a duplicate.
> The fix removes references to 8226420 from problemlist (the tests remain
> problem-listed due other issues).
Marked as reviewed by cjplummer (Reviewer).
-
PR Review:
On Tue, 5 Sep 2023 22:49:41 GMT, Erik Joelsson wrote:
> There are a number of files in the `test` directory that have an incorrect
> copyright header, which includes the "classpath" exception text. This patch
> removes that text from all test files that I could find it in. I did this
> using
On Wed, 6 Sep 2023 20:02:44 GMT, Alex Menkov wrote:
> To test ForceEarlyReturn command for NO_MORE_FRAMES case the test creates
> ThreadStartEventRequest with SUSPEND_ALL policy and requests debuggee to
> start new thread.
> If debuggee JVM starts some internal threads before the request is
On Fri, 8 Sep 2023 10:21:23 GMT, Soumadipta Roy wrote:
>> 8315770: serviceability/sa/TestJmapCoreMetaspace.java should run with
>> -XX:-VerifyDependencies
>>
>> serviceability/sa/TestJmapCoreMetaspace.java runs in hotspot:tier2, and
>> takes about 330 seconds out of 670 seconds of the entire
On Mon, 11 Sep 2023 11:02:04 GMT, Soumadipta Roy wrote:
>> 8315770: serviceability/sa/TestJmapCoreMetaspace.java should run with
>> -XX:-VerifyDependencies
>>
>> serviceability/sa/TestJmapCoreMetaspace.java runs in hotspot:tier2, and
>> takes about 330 seconds out of 670 seconds of the entire
On Thu, 31 Aug 2023 07:55:01 GMT, Aleksey Shipilev wrote:
> Current vmTestbase/nsk/monitoring/stress/classload tests contains 24 tests,
> each running exclusively. This drags the tier4 test times up. There seem to
> be no reason to run these tests exclusively, though: they complete in
>
On Thu, 7 Sep 2023 21:34:50 GMT, Chris Plummer wrote:
> Overall the changes look good. Have you tested to see if this fixes
> [JDK-8276210](https://bugs.openjdk.org/browse/JDK-8276210) and
> [JDK-8248675](https://bugs.openjdk.org/browse/JDK-8248675)? You'll need to
> remo
On Fri, 8 Sep 2023 12:34:39 GMT, Andrew Haley wrote:
>> This PR fixes a specific problem caused by using r29/rfp to unwind Java
>> code. For some time we have treated r29 as a callee-saved scratch register,
>> and it is freely used by C2-generated code. Therefore, any code in SA that
>> uses
On Tue, 12 Sep 2023 23:31:31 GMT, Chris Plummer wrote:
> [JDK-8276210](https://bugs.openjdk.org/browse/JDK-8276210) no longer seems to
> be reproducing, even before
> [JDK-8313800](https://bugs.openjdk.org/browse/JDK-8313800) was just pushed.
> I'm not sure what may have fixed
On Thu, 14 Sep 2023 19:08:14 GMT, Chris Plummer wrote:
>> This PR includes a couple of clarifications of the JDWP and JDI invoke
>> method support. The first is that deadlocks can occur due to a needed
>> "resource" being held. The spec previously just menti
On Tue, 12 Sep 2023 23:23:39 GMT, Chris Plummer wrote:
> [JDK-8248675](https://bugs.openjdk.org/browse/JDK-8248675) no longer seems to
> be reproducing, even before
> [JDK-8313800](https://bugs.openjdk.org/browse/JDK-8313800) was just pushed.
> I'm not sure what may have fixed
om.sun.jdi.ThreadReference,com.sun.jdi.Method,java.util.List,int)
>
> https://cr.openjdk.org/~cjplummer/8301639/docs.01/api/jdk.jdi/com/sun/jdi/ObjectReference.html#invokeMethod(com.sun.jdi.ThreadReference,com.sun.jdi.Method,java.util.List,int)
Chris Plummer has updated the pull request incrementally with
On Tue, 12 Sep 2023 22:24:18 GMT, Chris Plummer wrote:
> This PR includes a couple of clarifications of the JDWP and JDI invoke method
> support. The first is that deadlocks can occur due to a needed "resource"
> being held. The spec previously just mentioned
On Tue, 12 Sep 2023 23:31:31 GMT, Chris Plummer wrote:
> [JDK-8276210](https://bugs.openjdk.org/browse/JDK-8276210) no longer seems to
> be reproducing, even before
> [JDK-8313800](https://bugs.openjdk.org/browse/JDK-8313800) was just pushed.
> I'm not sure what may have fixed
On Wed, 13 Sep 2023 03:16:03 GMT, Leonid Mesnik wrote:
> Fine with fix, assuming you verified that test doesn't fail with Xcomp on
> linux-aarch64.
Yes, I tested with 100s of runs on linux-aarch64 with -Xcomp. Can I push this
as a trivial change?
-
PR Comment:
I think it should return false like is does with verify_tag(). This will
cause the test to fail, which it what we would want in this case
Chris
On 9/13/23 11:20 PM, David Holmes wrote:
Hi Julian,
This is a serviceability issue - cc'd.
On 14/09/2023 12:48 pm, Julian Waters wrote:
Hi all,
On Fri, 15 Sep 2023 23:18:06 GMT, Leonid Mesnik wrote:
> The test is updated to start the target VM with tested flags in addition to
> heap size.
> Tested with tier1, and iter5/6 rt/svc with CI flags.
Marked as reviewed by cjplummer (Reviewer).
-
PR Review:
On Wed, 23 Aug 2023 22:58:05 GMT, Leonid Mesnik wrote:
> Mark 3 tests as flagless to don't run them if not needed. Also, small clean
> up.
Is there a reason we don't want to run the subprocess with the test flags?
-
PR Comment:
On Fri, 1 Sep 2023 02:00:04 GMT, Yi Yang wrote:
>> This is a follow-up patch of #13667. verifyHeapDump is duplicated in several
>> tests, this patch tries to consolidate them into one method.
>
> Yi Yang has updated the pull request incrementally with one additional commit
> since the last
On Fri, 1 Sep 2023 23:01:01 GMT, Leonid Mesnik wrote:
>> The fix changes test serviceability/jdwp/AllModulesCommandTest.java to
>> accept VM flags.
>> 1) The 'ProcessTools.createTestJvm(JDWP_OPT, DEBUGGEE);' is used to start
>> debugee
>> 2) The stderr is just logging and tests doesn't check
On Wed, 23 Aug 2023 22:58:05 GMT, Leonid Mesnik wrote:
> Mark 3 tests as flagless to don't run them if not needed. Also, small clean
> up.
As long as we have other test coverage for passing the flags to the sub process
then I think these can do without.
-
PR Comment:
d the pull request incrementally with one additional
> commit since the last revision:
>
> Update test/hotspot/jtreg/serviceability/jdwp/DebuggeeLauncher.java
>
> Co-authored-by: Chris Plummer
test/hotspot/jtreg/serviceability/jdwp/DebuggeeLauncher.java line 66:
> 64:
On Fri, 1 Sep 2023 22:02:10 GMT, Alex Menkov wrote:
> So JDK-8226420 can be closed as a duplicate
You can't both close the CR as a duplicate and also use it as the CR to remove
the problem list references. Perhaps you should use a subtask of JDK-8240711 or
JDK-8226420 for this problem list
[JDK-8276210](https://bugs.openjdk.org/browse/JDK-8276210) no longer seems to
be reproducing, even before
[JDK-8313800](https://bugs.openjdk.org/browse/JDK-8313800) was just pushed. I'm
not sure what may have fixed it, but even if the bug was potentially still
there, it has likely been fixed
This PR includes a couple of clarifications of the JDWP and JDI invoke method
support. The first is that deadlocks can occur due to a needed "resource" being
held. The spec previously just mentioned monitors being held, but this is too
specific. The second is to clarify that an invoke on a
[JDK-8248675](https://bugs.openjdk.org/browse/JDK-8248675) no longer seems to
be reproducing, even before
[JDK-8313800](https://bugs.openjdk.org/browse/JDK-8313800) was just pushed. I'm
not sure what may have fixed it, but even if the bug was potentially still
there, it has likely been fixed
On Wed, 13 Sep 2023 13:01:32 GMT, Alan Bateman wrote:
>> Of course as soon as I posted that I now realize the issue. There are more
>> things that could "deadlock" virtual threads when all other threads are
>> suspended - such as calling sleep, because it requires a "system" thread to
>> be
On Tue, 12 Sep 2023 19:20:16 GMT, Aleksey Shipilev wrote:
> Similar to [JDK-8315437](https://bugs.openjdk.org/browse/JDK-8315437),
> current vmTestbase/nsk/monitoring/stress/lowmem tests contains 36 tests, each
> running exclusively. This drags the tier4 test times up. There seem to be no
>
On Wed, 23 Aug 2023 22:58:05 GMT, Leonid Mesnik wrote:
> Mark 3 tests as flagless to don't run them if not needed. Also, small clean
> up.
Marked as reviewed by cjplummer (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/15407#pullrequestreview-1625546191
On Thu, 7 Sep 2023 16:58:38 GMT, Andrew Haley wrote:
> … frame when invoking LambdaForms is involved
Overall the changes look good. Have you tested to see if this fixes
[JDK-8276210](https://bugs.openjdk.org/browse/JDK-8276210) and
[JDK-8248675](https://bugs.openjdk.org/browse/JDK-8248675)?
On Thu, 31 Aug 2023 01:34:44 GMT, David Holmes wrote:
> I'm not seeing how calling processDebuggeeOutput lets us "see" stderr? If
> there is nothing the test needs to read from stderr then I don't see any
> point in processing it.
I was thinking that maybe processDebuggeeOutput() should be
On Tue, 29 Aug 2023 13:46:08 GMT, Matthias Baesken wrote:
> The sun/tools/jhsdb tests have issues when we run them concurrently .
> So add a related config to TEST.root.
Marked as reviewed by cjplummer (Reviewer).
-
PR Review:
On Wed, 23 Aug 2023 18:26:03 GMT, Chris Plummer wrote:
>> During [JDK-8151815](https://bugs.openjdk.org/browse/JDK-8151815) it was
>> noted that the PerfMemory _initialized and _destroyed fields should be
>> volatile, but VMStructs didn't have the needed support
On Tue, 29 Aug 2023 09:12:51 GMT, Leo Korinth wrote:
>> Rename createJavaProcessBuilder so that it is not used by mistake instead of
>> createTestJvm.
>>
>> I have used the following sed script: `find -name "*.java" | xargs -n 1 sed
>> -i -e
>>
On Mon, 21 Aug 2023 21:47:14 GMT, Chris Plummer wrote:
> During [JDK-8151815](https://bugs.openjdk.org/browse/JDK-8151815) it was
> noted that the PerfMemory _initialized and _destroyed fields should be
> volatile, but VMStructs didn't have the needed support for doing that, so it
&
On Wed, 30 Aug 2023 22:15:52 GMT, Leonid Mesnik wrote:
>> test/hotspot/jtreg/serviceability/jdwp/DebuggeeLauncher.java line 107:
>>
>>> 105: @Override
>>> 106: public void onStringRead(StreamHandler handler, String line) {
>>> 107: processDebuggeeOutput(line);
>>
>> So the fix
On Wed, 30 Aug 2023 22:57:00 GMT, Leonid Mesnik wrote:
>> Test failed because of unexpected output of version string.
>> The standard convention for tests is to skip any unexpected output (version
>> string, VM warning, vm logging) and only fail on expected error patterns.
>> Fix is tested by
On Wed, 13 Sep 2023 14:34:42 GMT, Kevin Walls wrote:
> Original failure in 8081569 is a long time ago, and not reproducing.
> Other failures recorded there may be different problems, some of them are
> port related which are helped by other changes since these tests were
> problemlisted.
>
>
On Wed, 6 Sep 2023 16:06:29 GMT, Erik Joelsson wrote:
> > I wonder if this is the right thing to do for the hprof files. I believe
> > they originated from some hprof tools that we no longer ship. 3rd parties
> > might choose to integrate them into their own tools.
>
> Do you think I should
On Mon, 16 Oct 2023 16:34:40 GMT, Johannes Bechberger
wrote:
>> `if (!ex.thread().frame(0).location().equals(ex.location())) {` causes an
>> exception:
>>
>>
>> java.lang.IllegalArgumentException: Invalid method id: 139869509179824
>> at
>>
On Mon, 16 Oct 2023 16:01:39 GMT, Johannes Bechberger
wrote:
>> Fix `onthrow` issue by passing the event info to the `initialize` method.
>>
>> This prevents `jdb` from receiving a broken exception event and throwing an
>> internal NullPointerException, upon attaching to the JDWP-agent.
>
>
On Mon, 16 Oct 2023 19:07:37 GMT, Johannes Bechberger
wrote:
>> Fix `onthrow` issue by passing the event info to the `initialize` method.
>>
>> This prevents `jdb` from receiving a broken exception event and throwing an
>> internal NullPointerException, upon attaching to the JDWP-agent.
>
>
aching to the JDWP-agent.
>
> Johannes Bechberger has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Update test/jdk/com/sun/jdi/JdwpOnThrowTest.java
>
> Co-authored-by: Chris Plummer
I think I know the problem wit
aching to the JDWP-agent.
>
> Johannes Bechberger has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Update test/jdk/com/sun/jdi/JdwpOnThrowTest.java
>
> Co-authored-by: Chris Plummer
When running with `JTREG_TEST_THREAD
On Wed, 25 Oct 2023 16:53:18 GMT, Johannes Bechberger
wrote:
>> test/lib/jdk/test/lib/JDWP.java line 60:
>>
>>> 58: if (parts.length != 2) {
>>> 59: return null;
>>> 60: }
>>
>> This is a bit presumptuous in that it assumes that the first 2 token line of
>> output
On Wed, 25 Oct 2023 11:27:18 GMT, Johannes Bechberger
wrote:
> Fix race condition in debugger port selection, introduced with
> [JDK-8317920](https://bugs.openjdk.org/browse/JDK-8317920).
>
> Tested on my Mac M1, but it doesn't contain platform-dependent code.
test/lib/jdk/test/lib/JDWP.java
On Wed, 25 Oct 2023 17:09:09 GMT, Chris Plummer wrote:
>> Making too many not enough assumptions. The other method didn't make
>> assumptions on the format of address and connection type, so I thought that
>> I shouldn't too. I could create a temporary shell file that mim
On Fri, 27 Oct 2023 08:19:13 GMT, Matthias Baesken wrote:
> The allow option of agentlib:jdwp has been introduced a long time ago (see
> JDK-8061228) and is documented here :
> https://docs.oracle.com/en/java/javase/17/docs/specs/jpda/conninv.html#oracle-vm-invocation-options
> However it is
On Mon, 30 Oct 2023 08:55:55 GMT, Matthias Baesken wrote:
>> The allow option of agentlib:jdwp has been introduced a long time ago (see
>> JDK-8061228) and is documented here :
>> https://docs.oracle.com/en/java/javase/17/docs/specs/jpda/conninv.html#oracle-vm-invocation-options
>> However it
On Thu, 26 Oct 2023 07:51:56 GMT, Johannes Bechberger
wrote:
>> Fix race condition in debugger port selection, introduced with
>> [JDK-8317920](https://bugs.openjdk.org/browse/JDK-8317920).
>>
>> Tested on my Mac M1, but it doesn't contain platform-dependent code.
>
> Johannes Bechberger has
On Wed, 18 Oct 2023 21:48:33 GMT, Johannes Bechberger
wrote:
>> Fix `onthrow` issue by passing the event info to the `initialize` method.
>>
>> This prevents `jdb` from receiving a broken exception event and throwing an
>> internal NullPointerException, upon attaching to the JDWP-agent.
>
>
aching to the JDWP-agent.
>
> Johannes Bechberger has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Update test/jdk/com/sun/jdi/JdwpOnThrowTest.java
>
> Co-authored-by: Chris Plummer
I've included a fix. I'm still running it
On Wed, 18 Oct 2023 23:47:43 GMT, Serguei Spitsyn wrote:
>> Johannes Bechberger has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Add suggested fixes
>
> test/jdk/com/sun/jdi/JdwpOnThrowTest.java line 94:
>
>> 92:
On Mon, 18 Sep 2023 23:57:33 GMT, Liam Miller-Cushon wrote:
> For 748, it's handling a situation where IPv4 isn't specifically preferred.
> The implementation comment notes 'if preferredAddressFamily is AF_INET6 or
> not set'.
What does "specifically preferred" mean? By default it will be set
On Tue, 19 Sep 2023 05:30:39 GMT, David Holmes wrote:
> Okay I see now that `ai` is not important. We won't have set `listenAddr` so
> we will take the first `addrInfo`. But this seems somewhat random behaviour
> as the first `addrInfo` could be either V4 or V6 (what controls the order?).
>
On Mon, 18 Sep 2023 23:44:22 GMT, Chris Plummer wrote:
>> Liam Miller-Cushon has refreshed the contents of this pull request, and
>> previous commits have been removed. The incremental views will show
>> differences compared to the previous content of the PR. The pull reques
On Tue, 19 Sep 2023 07:28:52 GMT, Axel Boldt-Christmas
wrote:
> All the failing CDS tests pass now. Will rerun a full test suite to be sure.
> (There were two CDS test files that needed to be updated)
[JDK-8293507](https://bugs.openjdk.org/browse/JDK-8293507) is suppose to
address the CDS
On Thu, 14 Sep 2023 19:08:14 GMT, Chris Plummer wrote:
>> This PR includes a couple of clarifications of the JDWP and JDI invoke
>> method support. The first is that deadlocks can occur due to a needed
>> "resource" being held. The spec previously just menti
On Tue, 12 Sep 2023 22:24:18 GMT, Chris Plummer wrote:
> This PR includes a couple of clarifications of the JDWP and JDI invoke method
> support. The first is that deadlocks can occur due to a needed "resource"
> being held. The spec previously just mentioned
On Thu, 21 Sep 2023 21:58:15 GMT, Leonid Mesnik wrote:
> The code related to virtual threads support is moved into a separate class
> DebugeeWrapper.
>
> The code of method main() remains the same. I don't mix code change with
> moving code between files.
>
> Tesed by running
> make
On Fri, 22 Sep 2023 22:16:47 GMT, Leonid Mesnik wrote:
>> test/jdk/com/sun/jdi/TestScaffold.java line 555:
>>
>>> 553: if (mainWrapper != null &&
>>> !argInfo.targetAppCommandLine.isEmpty()) {
>>> 554: argInfo.targetVMArgs += "-D" +
>>> DebuggeeWrapper.PROPERTY_NAME + "="
On Fri, 22 Sep 2023 00:01:58 GMT, Liam Miller-Cushon wrote:
>> Please consider this fix for
>> [JDK-8313804](https://bugs.openjdk.org/browse/JDK-8313804), which adds
>> support to JDWP for `-Djava.net.preferIPv6Addresses=system`. Previously it
>> only handled
On Fri, 22 Sep 2023 21:40:14 GMT, Leonid Mesnik wrote:
>> The code related to virtual threads support is moved into a separate class
>> DebugeeWrapper.
>>
>> The code of method main() remains the same. I don't mix code change with
>> moving code between files.
>>
>> Tesed by running
>> make
On Fri, 22 Sep 2023 23:38:49 GMT, Leonid Mesnik wrote:
>> The code related to virtual threads support is moved into a separate class
>> DebugeeWrapper.
>>
>> The code of method main() remains the same. I don't mix code change with
>> moving code between files.
>>
>> Tesed by running
>> make
On Thu, 21 Sep 2023 06:21:25 GMT, Axel Boldt-Christmas
wrote:
>> ObjectMonitorIterator fails to return the most resent monitor added. It
>> start with returning the `nextOM()` ObjectMonitor from the `_head`
>> ObjectMonitor but fails to ever return the `_head` ObjectMonitor.
>> The current
On Thu, 21 Sep 2023 06:21:13 GMT, Axel Boldt-Christmas
wrote:
>> `inUseList` will end up with the same value as `inUseListHead`. The reason
>> the old code worked is because `getAddressField` does not type check and
>> `reinterpret_cast(::_in_use_list) ==
>>
On Sat, 16 Sep 2023 05:38:01 GMT, Alan Bateman wrote:
> > CSR has been created:
> > [JDK-8301639](https://bugs.openjdk.org/browse/JDK-8301639)
>
> I added the "csr" label as it was initially looking like this would involve a
> spec update. It's now changed to be non-normative and an API note
On Mon, 18 Sep 2023 11:55:24 GMT, Axel Boldt-Christmas
wrote:
> CDS tests are not happy with changing the class hierarchy of the LingeredApp.
> Unless it is easily solved for the CDS test I will revert those changes and
> have the 'TestObjectMonitorIterate' just do a less precise check of a
On Mon, 18 Sep 2023 12:11:24 GMT, Axel Boldt-Christmas
wrote:
>> ObjectMonitorIterator fails to return the most resent monitor added. It
>> start with returning the `nextOM()` ObjectMonitor from the `_head`
>> ObjectMonitor but fails to ever return the `_head` ObjectMonitor.
>> The current
On Thu, 21 Sep 2023 06:21:25 GMT, Axel Boldt-Christmas
wrote:
>> ObjectMonitorIterator fails to return the most resent monitor added. It
>> start with returning the `nextOM()` ObjectMonitor from the `_head`
>> ObjectMonitor but fails to ever return the `_head` ObjectMonitor.
>> The current
On Mon, 25 Sep 2023 16:16:51 GMT, Roman Kennke wrote:
> The SA can run concurrently with Java threads, SA code that inspects locking
> state should be able to deal with that. On the other hand, the particular
> code is only used in printing routine and is not expected to be precise. When
>
On Mon, 25 Sep 2023 10:05:12 GMT, Axel Boldt-Christmas
wrote:
> My understanding of the serviceability agent is very limited, but from what I
> understood the JVM does not run when we are attached. So no code should add
> to the list.
Your understanding is correct, although one thing SA has
On Thu, 28 Sep 2023 07:20:20 GMT, Varada M wrote:
>> Similar issue [JDK-8303549](https://bugs.openjdk.org/browse/JDK-8303549)
>> where AttachCurrentThread is failing on AIX due t stack size issue.
>> Test cases:
>> runtime/jni/terminatedThread/TestTerminatedThread.java
>>
On Thu, 28 Sep 2023 21:23:25 GMT, Ashutosh Mehra wrote:
> Please review this change to fix the operands of the bytecodes that operate
> on fields when dumping a class using SA.
>
> Testing: hotspot_serviceability
>
> I have also verified that
>
On Thu, 28 Sep 2023 21:23:25 GMT, Ashutosh Mehra wrote:
> Please review this change to fix the operands of the bytecodes that operate
> on fields when dumping a class using SA.
>
> Testing: hotspot_serviceability
>
> I have also verified that
>
On Thu, 28 Sep 2023 16:47:09 GMT, Leonid Mesnik wrote:
>> The main.wrapper was the first name for jtreg test thread factory plugin.
>> However, during integration of this feature in jtreg it was decided to use
>> test.thread.factory name. So this fix just renames "main.wrapper" property
>> to
On Thu, 28 Sep 2023 21:04:58 GMT, Leonid Mesnik wrote:
>> The test fails because ThreadDeath is raised during class
>> jdk.internal.misc.VirtualThreads initialization. The proposed fix is to
>> pre-initialize this step to avoid such failures. See more details in the bug.
>> I reproduced the
On Thu, 28 Sep 2023 16:38:07 GMT, Varada M wrote:
> I have performed jtreg testing
Yes, but what testing and on which platforms?
-
PR Comment: https://git.openjdk.org/jdk/pull/15924#issuecomment-1739789244
On Mon, 25 Sep 2023 19:59:32 GMT, Roman Kennke wrote:
> The specific race here is that SA sees an anonymously locked ObjectMonitor
> and tries to find the owning thread, and fails, presumably because that
> thread has moved on and unlocked the object in the meantime.
But you said that when T1
On Mon, 25 Sep 2023 14:33:15 GMT, Chris Plummer wrote:
> This code is called when you choose the hsdb "Tools -> Monitor Cache Dump"
> menu item. Have you tried doing that? I tried running it against a clhsdb
> process, and currently it doesn't seem to show any moni
On Mon, 25 Sep 2023 18:32:19 GMT, Roman Kennke wrote:
>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Threads.java
>> line 247:
>>
>>> 245: // Java code and locking state can change at any time.
>>> This code is not
>>> 246: // expected to be
On Wed, 27 Sep 2023 21:34:37 GMT, Alex Menkov wrote:
> The change fixes 2 issues in hprof test library.
> The issue were discovered during test development (logging values of dumped
> heap objects).
> - JavaValueArray.elementSize cannot determine size of the array elements and
> throws
On Thu, 28 Sep 2023 21:23:25 GMT, Ashutosh Mehra wrote:
> Please review this change to fix the operands of the bytecodes that operate
> on fields when dumping a class using SA.
>
> Testing: hotspot_serviceability
>
> I have also verified that
>
On Thu, 28 Sep 2023 16:44:26 GMT, Varada M wrote:
>> Similar issue [JDK-8303549](https://bugs.openjdk.org/browse/JDK-8303549)
>> where AttachCurrentThread is failing on AIX due t stack size issue.
>> Test cases:
>> runtime/jni/terminatedThread/TestTerminatedThread.java
>>
On Tue, 26 Sep 2023 12:02:52 GMT, David Holmes wrote:
>> Ok!
>> So we would have to swap the popping and state-update at least. Unless we
>> insert members between them, the updates would still be observable in any
>> order, I suppose, but inserting membars just to make SA happy seems a bit
On Tue, 26 Sep 2023 22:10:15 GMT, Chris Plummer wrote:
>> Switching the order did not fix the problem.
>>
>> Even if we end up resolving that this is just something that can happen when
>> SA inspects things, I'd prefer to understand how this can arise. I guess I
On Tue, 26 Sep 2023 02:42:56 GMT, Chris Plummer wrote:
>> Correction, there is one code path where we pop the lockstack first and then
>> update the owner:
>>
>> ObjectMonitor* monitor = inflate(current, object, inflate_cause_vm_internal);
>> if (LockingMod
On Tue, 26 Sep 2023 02:34:08 GMT, David Holmes wrote:
>> AFAICS we update the owner to the real thread before we remove the object
>> from the lock stack. So if we see the object monitor is anonymously owned
>> then we should find the monitor object in a thread's lockstack.
>
> Correction,
On Tue, 26 Sep 2023 02:44:59 GMT, Chris Plummer wrote:
>> Maybe SA is seeing a monitor in the monitor cache that it is only seeing
>> because the monitor cache is currently inconsistent (due to SA not safe
>> pointing). So the question is whether the monitor cache can be in
On Tue, 26 Sep 2023 02:14:40 GMT, David Holmes wrote:
> Ah! I guess we get used to talking about "at a safepoint" when we really mean
> "at a fixed point in time". So the VM is not necessarily at a safepoint, but
> everything is fixed. So invariants may not hold, but the state cannot change.
On Tue, 26 Sep 2023 01:32:48 GMT, David Holmes wrote:
>> If the SA is working from a snapshot then it has to create that snapshot
>> atomically. It can't snapshot the threads, then snapshot the heap.
>
> Correction to above:
>
> threads = VM.getVM().getThreads();
> heap =
On Tue, 26 Sep 2023 02:48:17 GMT, Chris Plummer wrote:
>> Looks like you answered my question while I was asking it.
>
> And I shouldn't have said "cache". I was confusing this PR with another
> dealing with the Monitor Cache.
...although that is a pretty small
On Tue, 26 Sep 2023 04:52:00 GMT, David Holmes wrote:
>> Ok, so we are not (usually) at a safepoint, but no threads are moving. But
>> the snapshot can not be taken atomically. Which means that the
>> anonymous-state in the ObjectMonitor and the state of the lock-stack are not
>> necessarily
On Tue, 26 Sep 2023 20:41:33 GMT, David Holmes wrote:
>> I'm not seeing that this code has much impact on the failure rate. I've
>> tried changing the order and also have tried adding a nanosleep(). Always
>> fails at about the same rate.
>
> Switching the order did not fix the problem.
>
>
On Tue, 26 Sep 2023 22:55:27 GMT, Chris Plummer wrote:
>> Yeah, I also haven't seen a good explanation for why this is happening yet.
>> I'll also look into SA, but I don't understand the hotspot code it is trying
>> to emulate that well so not sure how useful I'll be.
>
On Wed, 27 Sep 2023 17:54:51 GMT, Roman Kennke wrote:
>> The SA can run concurrently with Java threads, SA code that inspects locking
>> state should be able to deal with that. On the other hand, the particular
>> code is only used in printing routine and is not expected to be precise.
>>
On Wed, 27 Sep 2023 20:45:00 GMT, Ashutosh Mehra wrote:
> Please review trivial fix to display class name in the output of "where"
> command of SA.
>
> Testing: hotspot_serviceability
Can you add to the CR a copy of the `where` output after this fix? Just a short
snippet equivalent to the
On Wed, 27 Sep 2023 15:52:47 GMT, Chris Plummer wrote:
>> Is it like we should create separate PR to remove/add tests from ProblemList
>> or can I remove those from ProblemList in this PR itself. One of the test
>> "TestTerminatedThread.java" still fails so it
On Thu, 14 Sep 2023 17:24:39 GMT, Kevin Walls wrote:
> This assert happens rarely, but is seen in testing a few times.
>
> getCurrentQueryIndexForProcess comments that it can return -1, but it asserts
> that the value is >=0
>
> If we let it return -1 for failure as its comment documents, the
1 - 100 of 1438 matches
Mail list logo
