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, so now a
On Mon, 8 Jul 2024 18:13:33 GMT, Chris Plummer wrote:
>> There are two similarly names tests.
>> Recently:
>> JDK-8335124: com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java failed
>> with CPU time out of expected range
>> ...made a simple change to try and avoid noisy test failures. The s
On Thu, 4 Jul 2024 10:08:30 GMT, Kevin Walls wrote:
> There are two similarly names tests.
> Recently:
> JDK-8335124: com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java failed
> with CPU time out of expected range
> ...made a simple change to try and avoid noisy test failures. The same fix
On Wed, 3 Jul 2024 08:24:43 GMT, Kevin Walls wrote:
> Clean backport to jdk23 of a simple test update, to try and avoid spurious
> failures.
Looks good.
-
Marked as reviewed by cjplummer (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/1#pullrequestreview-2164031769
On Mon, 8 Jul 2024 12:16:51 GMT, KIRIYAMA Takuya wrote:
>> This bug was introduced by JDK-8284161. "Object.wait (long timeoutMillis)"
>> was changed to call "Object.wait0 (long timeoutMillis)" in JDK-8284161.
>>
>> When "jhdsb jstack" is executed, the stack and lock information are printed
>>
> 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
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` and `VM_Paral
> 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 14:26:29 GMT, Matthias Baesken wrote:
> Hi Severin, sure ! I put it into our build/test setup .
Thanks!
-
PR Comment: https://git.openjdk.org/jdk/pull/20076#issuecomment-2214368557
On Mon, 8 Jul 2024 12:13: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
>> lo
On Mon, 8 Jul 2024 14:24:12 GMT, Severin Gehwolf wrote:
> @MBaesken Since you've noticed the failing test in your CI could you please
> verify the issue is gone with this? I don't have an Alpine Linux setup to
> easily test this exclusion. Thanks!
Hi Severin, sure ! I put it into our build/t
On Mon, 8 Jul 2024 14:19:21 GMT, Severin Gehwolf wrote:
> Please review this simple test fix to exclude the test from being run on an
> Alpine Linux system. Apparently default Alpine Linux systems don't have
> cgroups set up by default the way other distros do. More info on the bug. I
> propos
On Mon, 8 Jul 2024 14:19:21 GMT, Severin Gehwolf wrote:
> Please review this simple test fix to exclude the test from being run on an
> Alpine Linux system. Apparently default Alpine Linux systems don't have
> cgroups set up by default the way other distros do. More info on the bug. I
> propos
Please review this simple test fix to exclude the test from being run on an
Alpine Linux system. Apparently default Alpine Linux systems don't have cgroups
set up by default the way other distros do. More info on the bug. I propose to
not run the test on musl systems.
-
Commit mess
On Mon, 8 Jul 2024 06:52:34 GMT, David Holmes wrote:
>> KIRIYAMA Takuya has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8335743: jhsdb jstack cannot print some information on the waiting thread
>
> test/hotspot/jtreg/serviceability/sa/Li
On Mon, 8 Jul 2024 12:13: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
>> lo
> This bug was introduced by JDK-8284161. "Object.wait (long timeoutMillis)"
> was changed to call "Object.wait0 (long timeoutMillis)" in JDK-8284161.
>
> When "jhdsb jstack" is executed, the stack and lock information are printed
> in "sun.jvm.hotspot.runtime.JavaVFrame.printLockInfo(PrintStrea
> 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 10:58:29 GMT, Thomas Wuerthinger wrote:
> OK. Will there be a CSR or JEP for this?
There is no plan for this, nor should it be required. It’s an internal
implementation.
> When do you approximately expect this to land in main line?
ASAP. Compatibility for the field name i
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.lang.RuntimeExce
On Mon, 8 Jul 2024 08:18:42 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 looser
>
On Mon, 8 Jul 2024 09:39:32 GMT, Thomas Wuerthinger wrote:
> Is this change expected to require JVMCI and/or Graal JIT changes?
Support for `UseObjectMonitorTable` would require changes to Graal JIT.
(`UseObjectMonitorTable` is off by default).
Minimal support would be to call into the VM for
On Mon, 8 Jul 2024 08:18:42 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 looser
>
On 03/07/2024 11:26, Thiago Henrique Hupner wrote:
Dear JDK developers,
I'd like to propose adding an option that allows the JVM to ignore a
non-existent -javaagent instead of aborting.
Currently, if a -javaagent is specified but the agent jar file doesn't
exist, the JVM aborts with an error
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 also contai
On Thu, 4 Jul 2024 12:57:09 GMT, Thomas Stuefe wrote:
> The new System.map facility fails its tests when the JVM is using ZGC. The
> facility is working fine, but the test checks for the java heap to appear as
> committed non-shared memory segment, but on ZGC we reserve the memory as
> shared
On Mon, 8 Jul 2024 06:46:34 GMT, David Holmes wrote:
>> Thomas Stuefe has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> problemlist
>
> Seems okay.
>
> Thanks for fixing.
Thanks @dholmes-ora and @jerboaa
-
PR Comment: https
27 matches
Mail list logo
