On Wed, 31 Jul 2024 10:52:06 GMT, Kevin Walls wrote:
> Problemlist update only, should be trivial:
>
> Remove problemlist entries for sun/management/jdp tests on MacOS and Linux.
>
> 8241865 was a failure last seen July 2022.
> Was related to
> 8241530 com/sun/jdi tests fail due to network
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
>
On Fri, 12 Jul 2024 03:24:42 GMT, SendaoYan wrote:
> Hi all,
> Test TestClhsdbJstackLock.java/TestJhsdbJstackLock.java fails with -Xcomp
> after [JDK-8335743](https://bugs.openjdk.org/browse/JDK-8335743). I think the
> new failures was testcase bug.
>
>
On Wed, 3 Jul 2024 13:58:51 GMT, Kevin Walls wrote:
> CmdLine::is_executable() looks wrong, surely an empty line is not executable.
>
> With this change, in DCmd::parse_and_execute() we will avoid needlessly
> entering the code block to try and execute the command.
>
> DCmd tests all good:
>
On Fri, 12 Jul 2024 17:02:56 GMT, Chris Plummer wrote:
>> The original code had 2 vm.resume() - one on them to match vm.suspend() and
>> 2nd one to allow debugee to continue on error.
>> Now we have 3 vm.resume() - one is to match vm.suspend() (line 377) and 2
>> conditional (on error).
>>
On Thu, 11 Jul 2024 22:36:05 GMT, Chris Plummer wrote:
>> The test hits a breakpoint on thread2 with SUSPEND_EVENT_THREAD policy, so
>> only thread2 is suspended. It then does a vm.suspend(), which suspends all
>> threads and bumps the suspendCount of thread2 up to 2. It then does an
>>
On 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 Wed, 10 Jul 2024 21:28:50 GMT, Chris Plummer wrote:
>> Thank you for the confirming the reason of the timeout.
>>
>> To be more clear about my point:
>> The test has 3 scenarios (see the test description):
>> ThreadReference.resume() resumes the thread suspended with:
>> * - with
On Fri, 31 May 2024 12:01:14 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this test-only change which addresses
>> https://bugs.openjdk.org/browse/JDK-8333130?
>>
>> There are a couple of tests `NativeMethodPrefixApp` and `RetransformApp`
>> under `test/jdk/java/lang/instrument/`
On Wed, 15 May 2024 06:00:46 GMT, Serguei Spitsyn wrote:
>> I'm not sure this answered Chris' query properly. Or I'm reading Chris'
>> query wrong.
>>
>> Perhaps this is not what Chris had in mind, but I'm wondering what happens
>> in some
>> Thread-A when it is checked and passed by but then
On Mon, 13 May 2024 14:44:05 GMT, Stefan Karlsson wrote:
>> I rather have this explicit check. If MEMFLAGS>1byte, things break, and I
>> would like to make that explicit.
>>
>> That said, I can move this static assert to the header. I just wanted to
>> avoid including debug.hpp. My original
On Tue, 30 Apr 2024 01:49:31 GMT, Serguei Spitsyn wrote:
>> src/hotspot/share/prims/jvmtiThreadState.cpp line 366:
>>
>>> 364: attempts--;
>>> 365: }
>>> 366: DEBUG_ONLY(if (attempts == 0) break;)
>>
>> Previously `_VTMS_transition_count` considered all threads at the
On Wed, 8 May 2024 01:19:05 GMT, SendaoYan wrote:
>> Hi,
>> GHA
>> [runner](https://github.com/sendaoYan/jdk-ysd/actions/runs/8881868940/job/24386063136)
>> shows that serviceability/dcmd/gc/RunFinalizationTest.java intermittent
>> fail on macos-aarch64. The testcase has been problemlisted
On Fri, 19 Apr 2024 01:16:46 GMT, Alex Menkov wrote:
> The fix deprecates -XX:+UseNotificationThread VM option
>
> Testing: tier1-3
Thumbs up.
Have you looked for any tests that are using this option?
-
Marked as reviewed by dcubed (Reviewer).
PR Review:
On Sat, 13 Apr 2024 23:35:07 GMT, Leonid Mesnik wrote:
> Please review the fix which excludes the test that failing intermittently.
Thumbs up. This is a trivial fix.
You originally had 8330131 as a sub-task of 8318729 which has only a
single sighting. Then I realized you were also including
On Wed, 3 Apr 2024 23:05:24 GMT, Coleen Phillimore wrote:
>> This change simplifies the code that grows the jmethodID cache in
>> InstanceKlass. Instead of lazily, when there's a rare request for a
>> jmethodID for an obsolete method, the jmethodID cache is grown during the
>>
On Wed, 3 Apr 2024 13:25:36 GMT, Coleen Phillimore wrote:
>> This change simplifies the code that grows the jmethodID cache in
>> InstanceKlass. Instead of lazily, when there's a rare request for a
>> jmethodID for an obsolete method, the jmethodID cache is grown during the
>>
On Mon, 1 Apr 2024 21:07:34 GMT, Daniel D. Daugherty wrote:
> Trivial fixes to ProblemList noisy tests:
>
> [JDK-8329425](https://bugs.openjdk.org/browse/JDK-8329425) ProblemList
> containers/docker/TestJFREvents.java on linux-x64
> [JDK-8329426](https://bugs.openjdk.org/bro
On Mon, 1 Apr 2024 22:15:06 GMT, David Holmes wrote:
>> Trivial fixes to ProblemList noisy tests:
>>
>> [JDK-8329425](https://bugs.openjdk.org/browse/JDK-8329425) ProblemList
>> containers/docker/TestJFREvents.java on linux-x64
>> [JDK-8329426](https://bugs.openjdk.org/browse/JDK-8329426)
Trivial fixes to ProblemList noisy tests:
[JDK-8329425](https://bugs.openjdk.org/browse/JDK-8329425) ProblemList
containers/docker/TestJFREvents.java on linux-x64
[JDK-8329426](https://bugs.openjdk.org/browse/JDK-8329426) ProblemList
On Mon, 1 Apr 2024 02:02:40 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which proposes to fix the test
> failure reported in https://bugs.openjdk.org/browse/JDK-8328273?
>
> As noted in that issue, the
> `sun/management/jmxremote/bootstrap/RmiRegistrySslTest.java`
On Fri, 29 Mar 2024 23:02:03 GMT, Serguei Spitsyn wrote:
>> So that would mean that the native side would always wait for 100 seconds?
>> Or will it wait for some increment of time upto a maximum of 100 seconds?
>
> It wait for some increment of time upto a maximum of 100 seconds.
I'm good with
On Fri, 29 Mar 2024 20:44:48 GMT, Serguei Spitsyn wrote:
>> runtime/8176717/TestInheritFD.java has an example of what I'm talking about:
>>
>> public static float timeoutFactor =
>> Float.parseFloat(System.getProperty("test.timeout.factor", "1.0"));
>> public static long
On Thu, 28 Mar 2024 23:29:53 GMT, Serguei Spitsyn wrote:
>> Caught this comment in passing. Delays like this should be scaled with
>> defaultTimeoutFactor so that test tasks that invoke tests with options
>> that can slow the test down, e.g., `-Xcomp`, can be accommodated.
>>
>> I believe the
On Wed, 27 Mar 2024 20:08:19 GMT, Chris Plummer wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> review: improve diagnostics and reliability
>
>
On Fri, 22 Mar 2024 19:26:33 GMT, Alex Menkov wrote:
>> The change fixes 3 nsk JDI tests.
>> Root cause in all 3 tests is the same - the tests requests JDI event with
>> SUSPEND_ALL policy, but event handler thread stops handle incoming event and
>> this causes debuggee to hang (suspended by
On Fri, 8 Mar 2024 06:05:09 GMT, Serguei Spitsyn wrote:
>> The implementation of the JVM TI `GetCurrentContendedMonitor()` does not
>> match the spec. It can sometimes return an incorrect information about the
>> contended monitor. Such a behavior does not match the function spec.
>> With
On Fri, 8 Mar 2024 06:05:09 GMT, Serguei Spitsyn wrote:
>> The implementation of the JVM TI `GetCurrentContendedMonitor()` does not
>> match the spec. It can sometimes return an incorrect information about the
>> contended monitor. Such a behavior does not match the function spec.
>> With
On Fri, 8 Mar 2024 06:11:23 GMT, Serguei Spitsyn wrote:
>> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the
>> spec.
>> The function returns the following structure:
>>
>>
>> typedef struct {
>> jthread owner;
>> jint entry_count;
>> jint waiter_count;
On Mon, 11 Mar 2024 18:08:14 GMT, Serguei Spitsyn wrote:
>> Sorry I missed this response. I can't see a way to address spurious wakeups
>> in this case as it needs to be a per-thread flag (so that each thread knows
>> it was notified) but you don't know which thread will be notified in any
>>
On Fri, 8 Mar 2024 06:11:23 GMT, Serguei Spitsyn wrote:
>> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the
>> spec.
>> The function returns the following structure:
>>
>>
>> typedef struct {
>> jthread owner;
>> jint entry_count;
>> jint waiter_count;
On Sun, 18 Feb 2024 14:56:03 GMT, Daniel D. Daugherty
wrote:
> Trivial fixes to ProblemList a couple of tests:
> [JDK-8326117](https://bugs.openjdk.org/browse/JDK-8326117) ProblemList
> serviceability/jvmti/vthread/SuspendWithInterruptLock/SuspendWithInterruptLock.java#default
> i
On Sun, 18 Feb 2024 16:28:51 GMT, Alan Bateman wrote:
>> Trivial fixes to ProblemList a couple of tests:
>> [JDK-8326117](https://bugs.openjdk.org/browse/JDK-8326117) ProblemList
>> serviceability/jvmti/vthread/SuspendWithInterruptLock/SuspendWithInterruptLock.java#default
>> in Xcomp mode
>>
Trivial fixes to ProblemList a couple of tests:
[JDK-8326117](https://bugs.openjdk.org/browse/JDK-8326117) ProblemList
serviceability/jvmti/vthread/SuspendWithInterruptLock/SuspendWithInterruptLock.java#default
in Xcomp mode
[JDK-8326120](https://bugs.openjdk.org/browse/JDK-8326120) ProblemList
On Wed, 14 Feb 2024 15:25:33 GMT, Serguei Spitsyn wrote:
>> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the
>> spec.
>> The function returns the following structure:
>>
>>
>> typedef struct {
>> jthread owner;
>> jint entry_count;
>> jint waiter_count;
On Wed, 14 Feb 2024 11:56:27 GMT, Serguei Spitsyn wrote:
> Thanks, Dan. I've pushed the suggested test changes but refactored them a
> little bit.
You are welcome. I presume the revised test passes with your fix in place. I
made the
test changes on a baseline repo and not a repo that had your
On Tue, 13 Feb 2024 08:39:38 GMT, Serguei Spitsyn wrote:
>> Sorry really struggling to understand this now. We have gone from a simple
>> miscalculation to apparently doing everything wrong.
>>
>> IIUC this API does not currently handle virtual threads correctly -i s that
>> the case? If so I
On Tue, 30 Jan 2024 10:47:22 GMT, Sebastian Lövdahl wrote:
> 8307977: jcmd and jstack broken for target processes running with elevated
> capabilities
Cool. Thanks for the confirmation.
-
PR Comment: https://git.openjdk.org/jdk/pull/17628#issuecomment-1934542288
On Thu, 8 Feb 2024 10:34:14 GMT, Serguei Spitsyn wrote:
>> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1521:
>>
>>> 1519: // we have contending and/or waiting threads
>>> 1520: if (nWant > 0) {
>>> 1521: // we have contending threads
>>
>> This block includes this logic:
On Tue, 30 Jan 2024 10:47:22 GMT, Sebastian Lövdahl wrote:
> 8307977: jcmd and jstack broken for target processes running with elevated
> capabilities
Will this result in files being left in /tmp that are not cleaned up during
test runs?
-
PR Comment:
On Wed, 7 Feb 2024 07:02:11 GMT, Serguei Spitsyn wrote:
>> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the
>> spec.
>> The function returns the following structure:
>>
>>
>> typedef struct {
>> jthread owner;
>> jint entry_count;
>> jint waiter_count;
On Thu, 18 Jan 2024 15:22:19 GMT, Daniel D. Daugherty
wrote:
> Trivial fixes to adjust more monitoring test timeouts.
>
> See the bug report for the gory timeout details.
This pull request has now been integrated.
Changeset: 79c3d47c
Author: Daniel D. Daugherty
URL:
On Thu, 18 Jan 2024 15:36:29 GMT, Albert Mingkun Yang wrote:
>> Trivial fixes to adjust more monitoring test timeouts.
>>
>> See the bug report for the gory timeout details.
>
> Marked as reviewed by ayang (Reviewer).
@albertnetymk and @kevinjwalls - Thanks for the fast reviews!
-
Trivial fixes to adjust more monitoring test timeouts.
See the bug report for the gory timeout details.
-
Commit messages:
- Backport 806ffb108572236cb9908ad6f93d7b09dfc6a600
Changes: https://git.openjdk.org/jdk22/pull/92/files
Webrev:
On Thu, 18 Jan 2024 05:16:33 GMT, Chris Plummer wrote:
>> Trivial fixes to adjust more monitoring test timeouts.
>>
>> See the bug report for the gory timeout details.
>
> Shouldn't we use a larger timeoutfactor for slowdebug builds?
@plummercj, @kevinjwalls and @sspitsyn - Thanks for the
On Thu, 18 Jan 2024 01:28:09 GMT, Daniel D. Daugherty
wrote:
> Trivial fixes to adjust more monitoring test timeouts.
>
> See the bug report for the gory timeout details.
This pull request has now been integrated.
Changeset: 806ffb10
Author: Daniel D. Daugherty
URL:
> Trivial fixes to adjust more monitoring test timeouts.
>
> See the bug report for the gory timeout details.
Daniel D. Daugherty has updated the pull request incrementally with one
additional commit since the last revision:
Update copyright years.
-
Changes:
- a
Trivial fixes to adjust more monitoring test timeouts.
See the bug report for the gory timeout details.
-
Commit messages:
- 8324082: more monitoring test timeout adjustments
Changes: https://git.openjdk.org/jdk/pull/17478/files
Webrev:
On Thu, 4 Jan 2024 15:37:33 GMT, Denghui Dong wrote:
>> Hi,
>>
>> Please help review this patch that fixes the failures of
>> FullGCHeapDumpLimitTest.java caused by passing other gc flags.
>>
>> Thanks.
>
> Denghui Dong has updated the pull request incrementally with one additional
> commit
A trivial fix to ProblemList
serviceability/HeapDump/FullGCHeapDumpLimitTest.java
on all platforms.
We're already up to 54 failures in Tier3 and Tier5.
-
Commit messages:
- 8323011: ProblemList serviceability/HeapDump/FullGCHeapDumpLimitTest.java
Changes:
On Thu, 4 Jan 2024 16:27:05 GMT, Alexander Zvegintsev
wrote:
>> A trivial fix to ProblemList
>> serviceability/HeapDump/FullGCHeapDumpLimitTest.java
>> on all platforms.
>>
>> We're already up to 54 failures in Tier3 and Tier5.
>
> Marked as reviewed by azvegint (Reviewer).
@azvegint and
On Thu, 4 Jan 2024 16:24:53 GMT, Daniel D. Daugherty wrote:
> A trivial fix to ProblemList
> serviceability/HeapDump/FullGCHeapDumpLimitTest.java
> on all platforms.
>
> We're already up to 54 failures in Tier3 and Tier5.
This pull request has now been integrated.
Changeset:
On Thu, 4 Jan 2024 15:37:33 GMT, Denghui Dong wrote:
>> Hi,
>>
>> Please help review this patch that fixes the failures of
>> FullGCHeapDumpLimitTest.java caused by passing other gc flags.
>>
>> Thanks.
>
> Denghui Dong has updated the pull request incrementally with one additional
> commit
On Tue, 5 Dec 2023 22:51:47 GMT, Serguei Spitsyn wrote:
>> This is a trivial fix for a regression caused by:
>> [8308614](https://bugs.openjdk.org/browse/JDK-8308614) Enabling JVMTI
>> ClassLoad event slows down vthread creation by factor 10
>>
>> The fix of 8308614 just triggered a known
On Sat, 2 Dec 2023 17:15:57 GMT, Daniel D. Daugherty wrote:
> In the fix for the following bug:
>
> [JDK-8319935](https://bugs.openjdk.org/browse/JDK-8319935) Ensure only one
> JvmtiThreadState is created for one JavaThread associated with attached
> native thread
>
On Mon, 4 Dec 2023 19:01:05 GMT, Jiangli Zhou wrote:
>> @dcubed-ojdk Thanks for the notification. I just ran one of our affected
>> test 100 times with JDK-8312174 change rolled back and with both following
>> applied:
>>
>> - https://git.openjdk.org/jdk/pull/16642
>> -
On Mon, 4 Dec 2023 18:13:50 GMT, Daniel D. Daugherty wrote:
>> Initially I thought this was not the right fix as we should not be exposing
>> an attaching thread that may still have a partially constructed `threadObj`.
>> But this issue shows that we must expose suc
On Mon, 4 Dec 2023 06:31:43 GMT, David Holmes wrote:
>> Daniel D. Daugherty has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> dholmes CR - adjust a comment.
>
> Initially I thought this was not the right fi
On Mon, 4 Dec 2023 05:16:59 GMT, Jiangli Zhou wrote:
>> In the fix for the following bug:
>>
>> [JDK-8319935](https://bugs.openjdk.org/browse/JDK-8319935) Ensure only one
>> JvmtiThreadState is created for one JavaThread associated with attached
>> native thread
>>
>>
h attached
> native thread
>
> since the test(s) for that fix are not yet integrated in the jdk/jdk repo.
Daniel D. Daugherty has updated the pull request incrementally with one
additional commit since the last revision:
dholmes CR - adjust a comment.
-
Chang
In the fix for the following bug:
[JDK-8319935](https://bugs.openjdk.org/browse/JDK-8319935) Ensure only one
JvmtiThreadState is created for one JavaThread associated with attached native
thread
JvmtiThreadState::state_for_while_locked() was changed to
return nullptr for attaching JNI threads
On Thu, 30 Nov 2023 21:27:27 GMT, Serguei Spitsyn wrote:
>> This is a fix of a performance/scalability related issue. The
>> `JvmtiThreadState` objects for virtual thread filtered events enabled
>> globally are created eagerly because it is needed when the
>> `interp_only_mode` is enabled.
On Thu, 30 Nov 2023 20:58:41 GMT, Serguei Spitsyn wrote:
> It is a little bit ugly to do it for each call site.
> The Handshake::execute() can do it instead, so its call sites could be
> simplified.
> BTW, it is done in the JvmtiHandshake::execute() and one can find it to be
> convenient.
On Thu, 30 Nov 2023 02:08:39 GMT, Serguei Spitsyn wrote:
>> This is a fix of a performance/scalability related issue. The
>> `JvmtiThreadState` objects for virtual thread filtered events enabled
>> globally are created eagerly because it is needed when the
>> `interp_only_mode` is enabled.
On Thu, 30 Nov 2023 02:08:39 GMT, Serguei Spitsyn wrote:
>> This is a fix of a performance/scalability related issue. The
>> `JvmtiThreadState` objects for virtual thread filtered events enabled
>> globally are created eagerly because it is needed when the
>> `interp_only_mode` is enabled.
On Wed, 22 Nov 2023 22:40:20 GMT, Jiangli Zhou wrote:
>> Please review JvmtiThreadState::state_for_while_locked change to handle the
>> state->get_thread_oop() null case. Please see
>> https://bugs.openjdk.org/browse/JDK-8319935 for details.
>
> Jiangli Zhou has updated the pull request
On Fri, 17 Nov 2023 20:29:11 GMT, Serguei Spitsyn wrote:
>> This is a fix of a performance/scalability related issue. The
>> `JvmtiThreadState` objects for virtual thread filtered events enabled
>> globally are created eagerly because it is needed when the
>> `interp_only_mode` is enabled.
On Wed, 29 Nov 2023 06:38:51 GMT, Stefan Karlsson wrote:
>> In the rewrites made for:
>> [JDK-8318757](https://bugs.openjdk.org/browse/JDK-8318757) `VM_ThreadDump
>> asserts in interleaved ObjectMonitor::deflate_monitor calls`
>>
>> I removed the filtering of *owned ObjectMonitors with dead
On Mon, 27 Nov 2023 20:20:01 GMT, Stefan Karlsson wrote:
>> In the rewrites made for:
>> [JDK-8318757](https://bugs.openjdk.org/browse/JDK-8318757) `VM_ThreadDump
>> asserts in interleaved ObjectMonitor::deflate_monitor calls`
>>
>> I removed the filtering of *owned ObjectMonitors with dead
On Thu, 23 Nov 2023 11:21:12 GMT, Stefan Karlsson wrote:
>> test/hotspot/jtreg/serviceability/jvmti/GetOwnedMonitorInfo/GetOwnedMonitorInfoTest.java
>> line 61:
>>
>>> 59: jniMonitorEnter(obj);
>>> 60: obj = null;
>>> 61: System.gc();
>>
>> Again one gc() is generally
On Mon, 27 Nov 2023 20:20:01 GMT, Stefan Karlsson wrote:
>> In the rewrites made for:
>> [JDK-8318757](https://bugs.openjdk.org/browse/JDK-8318757) `VM_ThreadDump
>> asserts in interleaved ObjectMonitor::deflate_monitor calls`
>>
>> I removed the filtering of *owned ObjectMonitors with dead
On Sat, 18 Nov 2023 12:22:10 GMT, Serguei Spitsyn wrote:
>> src/hotspot/share/prims/jvmtiEventController.cpp line 374:
>>
>>> 372: // Protects any existing JavaThread's from being terminated while it
>>> is set.
>>> 373: // The FJP carrier thread compensating mechanism can create carrier
On Fri, 17 Nov 2023 20:29:11 GMT, Serguei Spitsyn wrote:
>> This is a fix of a performance/scalability related issue. The
>> `JvmtiThreadState` objects for virtual thread filtered events enabled
>> globally are created eagerly because it is needed when the
>> `interp_only_mode` is enabled.
On Tue, 14 Nov 2023 08:18:41 GMT, Roman Marchenko
wrote:
>> Zero'ing memory of extension event callbacks
>
> Roman Marchenko has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Fixing review comments
Sure. Here's the relevant sub-section
On Wed, 15 Nov 2023 02:24:17 GMT, Alex Menkov wrote:
> ProblemList 2 nsk jdi tests with Xcomp on all platforms
Thumbs up. This is a trivial fix.
-
Marked as reviewed by dcubed (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/16667#pullrequestreview-1732508536
On Tue, 14 Nov 2023 08:18:41 GMT, Roman Marchenko
wrote:
>> Zero'ing memory of extension event callbacks
>
> Roman Marchenko has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Fixing review comments
Doing a post integration review.
This is
On Mon, 13 Nov 2023 21:52:22 GMT, Jiangli Zhou wrote:
> Please review JvmtiThreadState::state_for_while_locked change to handle the
> state->get_thread_oop() null case. Please see
> https://bugs.openjdk.org/browse/JDK-8319935 for details.
@jianglizhou - I fixed a typo in the bug's synopsis
On Sun, 29 Oct 2023 14:12:00 GMT, Daniel D. Daugherty
wrote:
> A trivial fix to ProblemList
> serviceability/AsyncGetCallTrace/MyPackage/ASGCTBaseTest.java
> on linux-aarch64 in Xcomp mode.
>
> The test is already ProblemListed in -Xcomp mode for linux-x64.
This pull reque
A trivial fix to ProblemList
serviceability/AsyncGetCallTrace/MyPackage/ASGCTBaseTest.java
on linux-aarch64 in Xcomp mode.
The test is already ProblemListed in -Xcomp mode for linux-x64.
-
Commit messages:
- 8319067: ProblemList
On Wed, 25 Oct 2023 21:05:06 GMT, Daniel D. Daugherty
wrote:
> A trivia fix to ProblemList
> java/lang/management/MemoryMXBean/CollectionUsageThreshold.java in Xcomp.
This pull request has now been integrated.
Changeset: a542f739
Author:Daniel D. Daugherty
URL:
A trivia fix to ProblemList
java/lang/management/MemoryMXBean/CollectionUsageThreshold.java in Xcomp.
-
Commit messages:
- 8318843: ProblemList
java/lang/management/MemoryMXBean/CollectionUsageThreshold.java in Xcomp
Changes: https://git.openjdk.org/jdk/pull/16368/files
Webrev:
On Wed, 25 Oct 2023 21:11:01 GMT, Leonid Mesnik wrote:
>> A trivia fix to ProblemList
>> java/lang/management/MemoryMXBean/CollectionUsageThreshold.java in Xcomp.
>
> Thanks for fixing this!
@lmesnik - Thanks for the fast review! Just a ProblemListing and not a fix
though...
-
On Thu, 12 Oct 2023 19:26:10 GMT, Daniel D. Daugherty
wrote:
> Trivial ProblemListing for some tests:
>
> [JDK-8318038](https://bugs.openjdk.org/browse/JDK-8318038) ProblemList
> runtime/CompressedOops/CompressedClassPointers.java on two platforms
> [JDK-8318040](https://b
On Thu, 12 Oct 2023 19:54:17 GMT, Roger Riggs wrote:
>> Trivial ProblemListing for some tests:
>>
>> [JDK-8318038](https://bugs.openjdk.org/browse/JDK-8318038) ProblemList
>> runtime/CompressedOops/CompressedClassPointers.java on two platforms
>>
Trivial ProblemListing for some tests:
[JDK-8318038](https://bugs.openjdk.org/browse/JDK-8318038) ProblemList
runtime/CompressedOops/CompressedClassPointers.java on two platforms
[JDK-8318040](https://bugs.openjdk.org/browse/JDK-8318040) ProblemList
On Fri, 6 Oct 2023 20:47:22 GMT, Leonid Mesnik wrote:
> Test fixed to accept vm flags.
Hmmm... what kind of testing has been done to make sure that we don't
suddenly get a bunch of new failures by allowing this test to accept VM flags?
-
PR Comment:
On Mon, 18 Sep 2023 20:47:13 GMT, Daniel D. Daugherty
wrote:
> Change the default of LockingMode to LM_LIGHTWEIGHT from LM_LEGACY.
>
> This fix has been tested with 3 Mach5 Tier[1-8] runs and a 4th is in process.
That would be unexpected breakage indeed...
-
PR Comme
On Tue, 3 Oct 2023 17:53:27 GMT, Daniel D. Daugherty wrote:
> Trivial fixes to ProblemList noisy tests in the JDK22 CI;
>
> [JDK-8317446](https://bugs.openjdk.org/browse/JDK-8317446) ProblemList
> gc/arguments/TestNewSizeFlags.java on macosx-aarch64 in Xcomp
> [JDK
On Tue, 3 Oct 2023 18:30:44 GMT, Tobias Hartmann wrote:
>> Trivial fixes to ProblemList noisy tests in the JDK22 CI;
>>
>> [JDK-8317446](https://bugs.openjdk.org/browse/JDK-8317446) ProblemList
>> gc/arguments/TestNewSizeFlags.java on macosx-aarch64 in Xcomp
>>
Trivial fixes to ProblemList noisy tests in the JDK22 CI;
[JDK-8317446](https://bugs.openjdk.org/browse/JDK-8317446) ProblemList
gc/arguments/TestNewSizeFlags.java on macosx-aarch64 in Xcomp
[JDK-8317448](https://bugs.openjdk.org/browse/JDK-8317448) ProblemList
On Mon, 18 Sep 2023 20:47:13 GMT, Daniel D. Daugherty
wrote:
> Change the default of LockingMode to LM_LIGHTWEIGHT from LM_LEGACY.
>
> This fix has been tested with 3 Mach5 Tier[1-8] runs and a 4th is in process.
Good question.
@vnkozlov - who would be the right JVMCI/Graal perso
On Thu, 21 Sep 2023 20:39:32 GMT, Daniel D. Daugherty
wrote:
> A trivial fix to ProblemList
> serviceability/jvmti/RedefineClasses/RedefineLeakThrowable.java
> on all platforms. It's a new test and we already have 8 failure sightings in
> the JDK22 CI.
This pull request
On Thu, 21 Sep 2023 20:39:32 GMT, Daniel D. Daugherty
wrote:
> A trivial fix to ProblemList
> serviceability/jvmti/RedefineClasses/RedefineLeakThrowable.java
> on all platforms. It's a new test and we already have 8 failure sightings in
> the JDK22 CI.
Not sure why the bot h
On Thu, 21 Sep 2023 20:42:51 GMT, Calvin Cheung wrote:
>> A trivial fix to ProblemList
>> serviceability/jvmti/RedefineClasses/RedefineLeakThrowable.java
>> on all platforms. It's a new test and we already have 8 failure sightings in
>> the JDK22 CI.
>
> Looks good and trivial.
@calvinccheung
A trivial fix to ProblemList
serviceability/jvmti/RedefineClasses/RedefineLeakThrowable.java
on all platforms. It's a new test and we already have 8 failure sightings in
the JDK22 CI.
-
Commit messages:
- 8316695: ProblemList
On Wed, 20 Sep 2023 03:56:28 GMT, Leonid Mesnik wrote:
> Test start failing because of unexpected VM logging.
> The fix is to search expected string ignoring any unknown output from forked
> process.
> Tested with tier1 and by running test with various options used in CI.
Thumbs up. Please
On Mon, 18 Sep 2023 20:47:13 GMT, Daniel D. Daugherty
wrote:
> Change the default of LockingMode to LM_LIGHTWEIGHT from LM_LEGACY.
>
> This fix has been tested with 3 Mach5 Tier[1-8] runs and a 4th is in process.
This pull request has now been integrated.
Changeset: 455cfa
On Mon, 18 Sep 2023 21:36:55 GMT, David Holmes wrote:
>> Change the default of LockingMode to LM_LIGHTWEIGHT from LM_LEGACY.
>>
>> This fix has been tested with 3 Mach5 Tier[1-8] runs and a 4th is in process.
>
> Looks good. Thanks.
@dholmes-ora, @rkennke, and @stefank - Thanks for the
On Thu, 7 Sep 2023 19:17:42 GMT, Daniel D. Daugherty wrote:
> Trivial fixes to ProblemList some tests:
> - [JDK-8315877](https://bugs.openjdk.org/browse/JDK-8315877) ProblemList
> vmTestbase/nsk/jvmti/InterruptThread/intrpthrd003/TestDescription.java on
> macosx-aarch64
> - [JDK
Trivial fixes to ProblemList some tests:
- [JDK-8315877](https://bugs.openjdk.org/browse/JDK-8315877) ProblemList
vmTestbase/nsk/jvmti/InterruptThread/intrpthrd003/TestDescription.java on
macosx-aarch64
- [JDK-8315879](https://bugs.openjdk.org/browse/JDK-8315879) ProblemList
1 - 100 of 448 matches
Mail list logo
