On Mon, 7 Oct 2024 19:37:51 GMT, Sebastian Lövdahl wrote:
>> The fix is twofold.
>>
>> 1. Stop the main container after an iteration is done. The main container is
>> started with its runtime defined as 120 seconds, which means that each
>> iteration takes 120 seconds. In reality, one iteratio
On Tue, 8 Oct 2024 23:14:55 GMT, Daniel D. Daugherty wrote:
> A couple of trivial fixes to ProblemList some noisy tests:
> [JDK-8341803](https://bugs.openjdk.org/browse/JDK-8341803) ProblemList
> containers/docker/TestJcmdWithSideCar.java on linux-x64
> [JDK-8341805](https://bugs
On Tue, 8 Oct 2024 23:54:50 GMT, Paul Sandoz wrote:
>> A couple of trivial fixes to ProblemList some noisy tests:
>> [JDK-8341803](https://bugs.openjdk.org/browse/JDK-8341803) ProblemList
>> containers/docker/TestJcmdWithSideCar.java on linux-x64
>> [JDK-8341805](https://bugs.openjdk.org/browse/
A couple of trivial fixes to ProblemList some noisy tests:
[JDK-8341803](https://bugs.openjdk.org/browse/JDK-8341803) ProblemList
containers/docker/TestJcmdWithSideCar.java on linux-x64
[JDK-8341805](https://bugs.openjdk.org/browse/JDK-8341805) ProblemList five
mlvm/indy/func/jvmti tests in Xcomp
On Mon, 7 Oct 2024 19:50:46 GMT, Kevin Walls wrote:
>> Sebastian Lövdahl has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Have EventGeneratorLoop end after a more predictable duration
>
> Don't worry I'll close 8341518 as a duplicate.
@
On Tue, 1 Oct 2024 15:38:56 GMT, SendaoYan wrote:
>> Hi all,
>> Test `com/sun/tools/attach/PermissionTest.java` fails access denied after
>> [JDK-8327114](https://bugs.openjdk.org/browse/JDK-8327114). This testcase
>> need the `readlink` permission of file `/proc/self/ns/mnt` after
>> [JDK-832
On Fri, 30 Aug 2024 00:07:50 GMT, Alex Menkov wrote:
> The fix improves Attch API protocol and implements updated protocol on
> windows; shared code is ready to implement updated protocol support on other
> platforms.
> More detailed explanations on the 1st comment.
>
> Testing: tier1,tier2,ti
On Wed, 7 Aug 2024 17:13:06 GMT, Gerard Ziemski wrote:
> Please review this cleanup, where we rename `MEMFLAGS` to `MemType`.
>
> `MEMFLAGS` implies that we can use more than one at the same time, but those
> are exclusive values, so `MemType` is much more suitable name.
>
> There is a bunch o
On Thu, 22 Aug 2024 10:59:58 GMT, Kevin Walls wrote:
> which says "%t => -MM-DD_HH-MM-SS" so maybe we could follow that pattern
Another vote for the above time stamp pattern.
-
PR Comment: https://git.openjdk.org/jdk/pull/20568#issuecomment-2305273185
>
> The commit being backported was authored by Stefan Karlsson on 20 Aug 2024
> and was reviewed by Leonid Mesnik, Daniel D. Daugherty and David Holmes.
>
> Thanks!
Thumbs up. Re-reviewed via GitHub and compared
the JDK24 patch file with the JDK23 patch file.
-
On Tue, 20 Aug 2024 06:13:18 GMT, Stefan Karlsson wrote:
>> So in this test case:
>> `-Xlog:gc,gc+init`
>> you have it so that `true` is returned.
>>
>> With this line of code:
>> ```
>>const bool is_gc_exact_match = ts->contains(LogTag::_gc) && ts->ntags()
>> == 1;
>>
>> I would thin
On Mon, 19 Aug 2024 19:56:26 GMT, Stefan Karlsson wrote:
>> The `ClassLoadingMXBean` and `MemoryMXBean` APIs have `setVerbose` methods
>> to control verbose mode and `isVerbose` methods to query it. Some JCK tests
>> expect `setVerbose(false)` to disable verbose mode and, subsequently,
>> `isV
On Mon, 19 Aug 2024 19:56:26 GMT, Stefan Karlsson wrote:
>> The `ClassLoadingMXBean` and `MemoryMXBean` APIs have `setVerbose` methods
>> to control verbose mode and `isVerbose` methods to query it. Some JCK tests
>> expect `setVerbose(false)` to disable verbose mode and, subsequently,
>> `isV
On Mon, 19 Aug 2024 19:52:02 GMT, Stefan Karlsson wrote:
>> Update: Looks like the CSR says that's exactly what we want.
>
> Wait. This is not what the implementation does. If you specify -Xlog:gc and
> -Xlog:gc+init (using a real tag instead of foo), `get_verbose` will return
> true. It only c
On Mon, 19 Aug 2024 16:30:09 GMT, Daniel D. Daugherty
wrote:
>> The `ClassLoadingMXBean` and `MemoryMXBean` APIs have `setVerbose` methods
>> to control verbose mode and `isVerbose` methods to query it. Some JCK tests
>> expect `setVerbose(false)` to disable verbose mode
On Mon, 19 Aug 2024 15:39:02 GMT, Stefan Karlsson wrote:
> The `ClassLoadingMXBean` and `MemoryMXBean` APIs have `setVerbose` methods to
> control verbose mode and `isVerbose` methods to query it. Some JCK tests
> expect `setVerbose(false)` to disable verbose mode and, subsequently,
> `isVerbo
On Fri, 16 Aug 2024 16:31:01 GMT, Chris Plummer wrote:
>> There are issues with the test attaching to the debuggee too soon, and the
>> debug agent isn't ready. yet. This test is based on ProcessAttachTest, which
>> does not have this issue. I eventually realized the reason why is because
>> P
On Thu, 15 Aug 2024 21:12:20 GMT, Chris Plummer wrote:
> There are issues with the test attaching to the debuggee too soon, and the
> debug agent isn't ready. yet. This test is based on ProcessAttachTest, which
> does not have this issue. I eventually realized the reason why is because
> Proce
On Tue, 13 Aug 2024 17:24:19 GMT, Daniel D. Daugherty
wrote:
>> Axel Boldt-Christmas has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Remove the last OMWorld references
>> - Rename omworldtable_wor
On Wed, 14 Aug 2024 09:24:34 GMT, Axel Boldt-Christmas
wrote:
>> When inflating a monitor the `ObjectMonitor*` is written directly over the
>> `markWord` and any overwritten data is displaced into a displaced
>> `markWord`. This is problematic for concurrent GCs which needs extra care or
>> l
On Wed, 14 Aug 2024 09:35:10 GMT, Axel Boldt-Christmas
wrote:
>> src/hotspot/share/runtime/vframe.cpp line 252:
>>
>>> 250: if (mark.has_monitor()) {
>>> 251: ObjectMonitor* mon =
>>> ObjectSynchronizer::read_monitor(current, monitor->owner(), mark);
>>> 252:
On Tue, 13 Aug 2024 16:30:12 GMT, Axel Boldt-Christmas
wrote:
>> When inflating a monitor the `ObjectMonitor*` is written directly over the
>> `markWord` and any overwritten data is displaced into a displaced
>> `markWord`. This is problematic for concurrent GCs which needs extra care or
>> l
On Tue, 13 Aug 2024 14:56:32 GMT, Coleen Phillimore wrote:
>> Axel Boldt-Christmas has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Remove the last OMWorld references
>> - Rename omworldtable_work to object_monitor_table_work
>
> src/h
On Tue, 13 Aug 2024 14:52:03 GMT, Axel Boldt-Christmas
wrote:
>> When inflating a monitor the `ObjectMonitor*` is written directly over the
>> `markWord` and any overwritten data is displaced into a displaced
>> `markWord`. This is problematic for concurrent GCs which needs extra care or
>> l
On Mon, 15 Jul 2024 00:45:10 GMT, Axel Boldt-Christmas
wrote:
>> src/hotspot/share/runtime/lightweightSynchronizer.cpp line 401:
>>
>>> 399:
>>> 400: if (inserted) {
>>> 401: // Hopefully the performance counters are allocated on distinct
>>
>> It doesn't look like the counters are on d
On Tue, 13 Aug 2024 16:49:42 GMT, Daniel D. Daugherty
wrote:
>> Axel Boldt-Christmas has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Remove the last OMWorld references
>> - Rename omworldtable_wor
On Mon, 12 Aug 2024 15:58:14 GMT, Axel Boldt-Christmas
wrote:
>> When inflating a monitor the `ObjectMonitor*` is written directly over the
>> `markWord` and any overwritten data is displaced into a displaced
>> `markWord`. This is problematic for concurrent GCs which needs extra care or
>> l
On Tue, 13 Aug 2024 16:30:12 GMT, Axel Boldt-Christmas
wrote:
>> When inflating a monitor the `ObjectMonitor*` is written directly over the
>> `markWord` and any overwritten data is displaced into a displaced
>> `markWord`. This is problematic for concurrent GCs which needs extra care or
>> l
On Wed, 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 issu
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/SetFieldModificationWatch/setfmodw001/TestDescription.jav
On Fri, 12 Jul 2024 03:24:42 GMT, SendaoYan wrote:
> Hi all,
> Test TestClhsdbJstackLock.java/TestJhsdbJstackLock.java fails with -Xcomp
> after [JDK-8335743](https://bugs.openjdk.org/browse/JDK-8335743). I think the
> new failures was testcase bug.
>
> https://github.com/openjdk/jdk/blob/627a
On Wed, 3 Jul 2024 13:58:51 GMT, Kevin Walls wrote:
> CmdLine::is_executable() looks wrong, surely an empty line is not executable.
>
> With this change, in DCmd::parse_and_execute() we will avoid needlessly
> entering the code block to try and execute the command.
>
> DCmd tests all good:
> m
On Fri, 12 Jul 2024 17:02:56 GMT, Chris Plummer wrote:
>> The original code had 2 vm.resume() - one on them to match vm.suspend() and
>> 2nd one to allow debugee to continue on error.
>> Now we have 3 vm.resume() - one is to match vm.suspend() (line 377) and 2
>> conditional (on error).
>> Theo
On Thu, 11 Jul 2024 22:36:05 GMT, Chris Plummer wrote:
>> The test hits a breakpoint on thread2 with SUSPEND_EVENT_THREAD policy, so
>> only thread2 is suspended. It then does a vm.suspend(), which suspends all
>> threads and bumps the suspendCount of thread2 up to 2. It then does an
>> eventS
On 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 w
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 thread2.s
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/` w
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 in
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 o
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: https://git.openjdk.org/
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 831
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
>> RedefineClasses
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
>> RedefineClasses
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) Probl
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
vmTestbase/nsk/jvmti/scenarios/capability/CM03/cm03t001/TestDe
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` inter
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 subProcessTimeo
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 de
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
>
> test/hotspot/jtreg/serviceability/jvmti/vthread/PopFrameTest/libPop
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 JD
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 this
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 this
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: https://git.openjdk.org/jdk/
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: https://webrevs.openjdk.org/?repo=jdk22&pr=92
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 revi
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: https://webrevs.openjdk.org/?repo=jdk&pr=174
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 s
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: https://git.openjdk.org/
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 @ct
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.
Change
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 s
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 issu
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
>> - https://github.com/open
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 such a
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
>>
>> JvmtiThreadState::state_
ciated with 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.
--
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 r
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. Oth
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.
Agre
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. Oth
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. Oth
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 increme
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. Oth
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 obj
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 obj
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 n
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 obj
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
>
1 - 100 of 482 matches
Mail list logo
