On Thu, 11 Jul 2024 04:43:49 GMT, Chris Plummer wrote:
>>> mainThead is suspended and is holding a println related lock, and thread2
>>> is stuck on the 2nd log call in runt2 awaiting the same lock.
>>
>> The classic example of why suspension is fraught with peril - the target
>> must be guara
On Thu, 4 Jul 2024 14:39:50 GMT, Kevin Walls wrote:
> Test failure, reproducible running batches of tests at the same time on the
> same machine.
> The use of "jcmd TestApp ..." gathers more output than the test wants and
> than its regexes can handle.
>
> Using the PID to match only the wante
On Thu, 11 Jul 2024 03:45:38 GMT, Jaikiran Pai wrote:
> I would like to backport this test-only change into `jdk23`. This cleans up
> the incorrect problem listing that was caused by a change that we introduced
> in JDK 23 as part of https://bugs.openjdk.org/browse/JDK-8333130.
>
> This is a c
On Thu, 11 Jul 2024 03:45:38 GMT, Jaikiran Pai wrote:
> I would like to backport this test-only change into `jdk23`. This cleans up
> the incorrect problem listing that was caused by a change that we introduced
> in JDK 23 as part of https://bugs.openjdk.org/browse/JDK-8333130.
>
> This is a c
On Thu, 11 Jul 2024 03:45:38 GMT, Jaikiran Pai wrote:
> I would like to backport this test-only change into `jdk23`. This cleans up
> the incorrect problem listing that was caused by a change that we introduced
> in JDK 23 as part of https://bugs.openjdk.org/browse/JDK-8333130.
>
> This is a c
On Wed, 10 Jul 2024 20:10:07 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 Thu, 11 Jul 2024 09:25:52 GMT, Yudi Zheng wrote:
>> Axel Boldt-Christmas has updated the pull request incrementally with four
>> additional commits since the last revision:
>>
>> - Add extra comments in LightweightSynchronizer::inflate_fast_locked_object
>> - Fix typos
>> - Remove unused
> Unfortunately those 2 tests fail now on Linux Alpine (x86_64) :
> serviceability/dcmd/vm/SystemDumpMapTest.java
>
> Missing patterns in dump:
> 0x\\p{XDigit}+-0x\\p{XDigit}+ +\\d+ +[rwsxp-]+ +\\d+ +\\d+
> +(4K|8K|16K|64K|2M|16M|64M) +com.*\[vdso\]
> test SystemDumpMapTest.jmx(): failure
> java.
On Mon, 8 Jul 2024 11:06:45 GMT, Matthias Baesken wrote:
> Unfortunately those 2 tests fail now on Linux Alpine (x86_64) :
> serviceability/dcmd/vm/SystemDumpMapTest.java
>
> Missing patterns in dump:
> 0x\\p{XDigit}+-0x\\p{XDigit}+ +\\d+ +[rwsxp-]+ +\\d+ +\\d+
> +(4K|8K|16K|64K|2M|16M|64M) +co
On Thu, 11 Jul 2024 12:30:29 GMT, Matthias Baesken wrote:
>> Unfortunately those 2 tests fail now on Linux Alpine (x86_64) :
>> serviceability/dcmd/vm/SystemDumpMapTest.java
>>
>> Missing patterns in dump:
>> 0x\\p{XDigit}+-0x\\p{XDigit}+ +\\d+ +[rwsxp-]+ +\\d+ +\\d+
>> +(4K|8K|16K|64K|2M|16M|6
On Wed, 10 Jul 2024 09:41:08 GMT, Axel Boldt-Christmas
wrote:
>> src/hotspot/share/runtime/arguments.cpp line 1830:
>>
>>> 1828: FLAG_SET_CMDLINE(LockingMode, LM_LIGHTWEIGHT);
>>> 1829: warning("UseObjectMonitorTable requires LM_LIGHTWEIGHT");
>>> 1830: }
>>
>> Maybe we want this to
On Wed, 10 Jul 2024 09:41:37 GMT, Axel Boldt-Christmas
wrote:
>> src/hotspot/share/runtime/lightweightSynchronizer.cpp line 763:
>>
>>> 761: assert(mark.has_monitor(), "must be");
>>> 762: // The monitor exists
>>> 763: ObjectMonitor* monitor = ObjectSynchronizer::read_monitor(current,
>
On Thu, 11 Jul 2024 07:13:17 GMT, David Holmes wrote:
>> Which logging should be removed? Alex suggest the logging between
>> breakpoints 2 and 3, but even that is not enough. There is logging after
>> breakpoint 3, and that happens before the vm.resume() is done. I'm not
>> saying this can't
Follow-on from JDK-8207908.
Two tests are broken by that change:
sun/management/jmxremote/startstop/JMXStartStopTest.java
sun/management/jmxremote/startstop/JMXStatusPerfCountersTest.java
These are additional tests which use jcmd and an application name pattern to
find a process.
They sh
On Thu, 11 Jul 2024 14:51:18 GMT, Kevin Walls wrote:
> Follow-on from JDK-8207908.
>
> Two tests are broken by that change:
> sun/management/jmxremote/startstop/JMXStartStopTest.java
> sun/management/jmxremote/startstop/JMXStatusPerfCountersTest.java
>
> These are additional tests which u
> Follow-on from JDK-8207908.
>
> Two tests are broken by that change:
> sun/management/jmxremote/startstop/JMXStartStopTest.java
> sun/management/jmxremote/startstop/JMXStatusPerfCountersTest.java
>
> These are additional tests which use jcmd and an application name pattern to
> find a pr
On Thu, 11 Jul 2024 15:22:54 GMT, Chris Plummer wrote:
>> Kevin Walls has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> line
>
> test/jdk/sun/management/jmxremote/startstop/JMXStartStopTest.java line 351:
>
>> 349: pid
> The test hits a breakpoint on thread2 with SUSPEND_EVENT_THREAD policy, so
> only thread2 is suspended. It then does a vm.suspend(), which suspends all
> threads and bumps the suspendCount of thread2 up to 2. It then does an
> eventSet.resume(), which decrements the thread2 suspendCount to 1,
On Thu, 11 Jul 2024 14:09:57 GMT, Chris Plummer wrote:
>> Sorry I'm unclear on the different threads involved here. IIUC the
>> vm.suspend comes from the debugger, and the mainthread and thread-2 are both
>> threads in the debuggee, being suspended at different times?
>
> Yes. thread2 is suspen
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 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 20:29:37 GMT, Albert Mingkun Yang wrote:
>> Similar cleanup as https://github.com/openjdk/jdk/pull/19056 but in
>> Parallel. As a result, the corresponding code in `SerialHeap` and
>> `ParallelScavengeHeap` share much similarity.
>>
>> The easiest way to review is to start
On Thu, 11 Jul 2024 14:39:47 GMT, Guoxiong Li wrote:
>> Albert Mingkun Yang has updated the pull request with a new target base due
>> to a merge or a rebase. The incremental webrev excludes the unrelated
>> changes brought in by the merge/rebase. The pull request contains three
>> additional
> Similar cleanup as https://github.com/openjdk/jdk/pull/19056 but in Parallel.
> As a result, the corresponding code in `SerialHeap` and
> `ParallelScavengeHeap` share much similarity.
>
> The easiest way to review is to start from these two VM operations,
> `VM_ParallelCollectForAllocation` a
On Thu, 11 Jul 2024 17:10:58 GMT, Guoxiong Li wrote:
> If the successful young collection didn't release any memory (or only
> released little memory but not enough for allocation),
A successful young-gc often leave young-gen completely empty. Otherwise,
max-compaction full-gc should be run --
On Thu, 11 Jul 2024 16:01:27 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:58:13 GMT, Chris Plummer wrote:
>> Yes. thread2 is suspended via breakpoint (multiple times). mainThread is
>> suspended by the one place in the test that does a vm.suspend(), which is
>> near the end of the test. This is the problematic suspend because sometimes
>> it i
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 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 Thu, 11 Jul 2024 14:51:18 GMT, Kevin Walls wrote:
> Follow-on from JDK-8207908.
>
> Two tests are broken by that change:
> sun/management/jmxremote/startstop/JMXStartStopTest.java
> sun/management/jmxremote/startstop/JMXStatusPerfCountersTest.java
>
> These are additional tests which u
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
Short version:
Stop testing this test with -Xcomp by adding requires vm.compMode != "Xcomp"
Make additional typo fixes and tidyups while here, it's just shocking.
TestDescription.java contains the test definition, so the "requires" goes
there, with a comment.
Updates to from001.java are typos a
On Thu, 11 Jul 2024 21:08:20 GMT, Kevin Walls wrote:
> Short version:
> Stop testing this test with -Xcomp by adding requires vm.compMode != "Xcomp"
>
> Make additional typo fixes and tidyups while here, it's just shocking.
>
> TestDescription.java contains the test definition, so the "requires
> The test hits a breakpoint on thread2 with SUSPEND_EVENT_THREAD policy, so
> only thread2 is suspended. It then does a vm.suspend(), which suspends all
> threads and bumps the suspendCount of thread2 up to 2. It then does an
> eventSet.resume(), which decrements the thread2 suspendCount to 1,
On Thu, 11 Jul 2024 18:09:24 GMT, Albert Mingkun Yang wrote:
>> src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 478:
>>
>>> 476:
>>> 477: const bool clear_all_soft_refs = true;
>>> 478: do_full_collection_no_gc_locker(clear_all_soft_refs);
>>
>> If the young collection succ
On Thu, 11 Jul 2024 15:40:01 GMT, Guoxiong Li wrote:
>> Albert Mingkun Yang has updated the pull request with a new target base due
>> to a merge or a rebase. The incremental webrev excludes the unrelated
>> changes brought in by the merge/rebase. The pull request contains three
>> additional
On Thu, 11 Jul 2024 21:08:20 GMT, Kevin Walls wrote:
> Short version:
> Stop testing this test with -Xcomp by adding requires vm.compMode != "Xcomp"
>
> Make additional typo fixes and tidyups while here, it's just shocking.
>
> TestDescription.java contains the test definition, so the "requires
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 21:08:20 GMT, Kevin Walls wrote:
> Short version:
> Stop testing this test with -Xcomp by adding requires vm.compMode != "Xcomp"
>
> Make additional typo fixes and tidyups while here, it's just shocking.
>
> TestDescription.java contains the test definition, so the "requires
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, 4 Jul 2024 23:08:37 GMT, David Holmes wrote:
> My concern is that the logic was wrong and so you fixed it, but this then
> screams out for a test that would have detected the error, but you can't
> write a test because the line can never be empty, so that becomes an
> invariant rather
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
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.
The change has been verified by -Xmixed/-Xcomp(c2)/-Xcomp
-XX:TieredStopAtLevel=1(c1), only change the t
On Fri, 5 Jul 2024 14:06:39 GMT, Kevin Walls wrote:
> The test
> test/jdk/javax/management/remote/mandatory/connection/RMIConnector_NPETest.java
> should be removed.
>
> This test was added when 6984520 was fixed in 6u25. It has been
> problemlisted since JDK-8267123 removed RMI Activation (
On Fri, 12 Jul 2024 03:04:06 GMT, Serguei Spitsyn wrote:
> Do I understand this right that the suggestion is to add an explicit runtime
> check for non-emptiness and report an error if an empty line has been
> discovered? If so, then the `is_empty()`check can be removed from the
> `CmdLine::is
On Fri, 12 Jul 2024 02:44:28 GMT, David Holmes wrote:
>> Chris Plummer has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix copyright and jcheck error
>
> test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/resume/resume001.java
> line
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/0db4
> 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 looser
> semantics to use this displaced data. In Lilliput this data als
On Mon, 8 Jul 2024 11:06:45 GMT, Matthias Baesken wrote:
> Unfortunately those 2 tests fail now on Linux Alpine (x86_64) :
> serviceability/dcmd/vm/SystemDumpMapTest.java
>
> Missing patterns in dump:
> 0x\\p{XDigit}+-0x\\p{XDigit}+ +\\d+ +[rwsxp-]+ +\\d+ +\\d+
> +(4K|8K|16K|64K|2M|16M|64M) +co
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 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 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
snprintf has been available for all officially and unofficially supported
compilers for Windows, Visual Studio since version 2015 and gcc since, well,
forever. snprintf is conforming to C99 since the start when compiling using
gcc, and 2015 when using Visual Studio. Since it conforms to C99 and
53 matches
Mail list logo