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 Tue, 26 Sep 2023 05:03:13 GMT, Chris Plummer wrote:
>> @rkennke the "snapshot" is atomic - the target VM is suspended.
>
> Atomicity means guaranteeing that a 2 or more operations are executed as if
> they are single operation from the viewpoint of other threads. There's no
> such concept
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 Mon, 25 Sep 2023 14:26:00 GMT, Chris Plummer wrote:
>> It is not. It is the value of `_head` when ObjectSynchronizer is
>> initialised. 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
On Mon, 25 Sep 2023 10:19:19 GMT, Axel Boldt-Christmas
wrote:
>> test/hotspot/jtreg/serviceability/sa/TestObjectMonitorIterate.java line 1:
>>
>>> 1: /*
>>
>> This test still barely actually tests the iterator code.
>
> Agreed. Did not want to spend time learning the SA, but maybe I should.
On Tue, 26 Sep 2023 04:25:40 GMT, Roman Kennke wrote:
>> ...although that is a pretty small window and we are seeing this bug quite a
>> lot. Seems if the code in question was the issue, it would take 1000s of
>> iterations to reproduce.
>
> Ok, so we are not (usually) at a safepoint, but no
On Tue, 26 Sep 2023 03:07:14 GMT, Chris Plummer wrote:
>> 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 window and we are seeing this bug quite a
> lot. Seems if the code in question was the
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 window and we are seeing this
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 a state
>> where
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 (LockingMode == LM_LIGHTWEIGHT &&
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:30:25 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
On Tue, 26 Sep 2023 02:27:39 GMT, Chris Plummer 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
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:41:38 GMT, Chris Plummer wrote:
>> Correction to above:
>>
>> threads = VM.getVM().getThreads();
>> heap = VM.getVM().getObjectHeap();
>> createThreadTable(); // calls getThreads() again
>>
>> The VM caches the set of threads ie the snapshot, so three sets are not
>>
On Mon, 25 Sep 2023 09:20:20 GMT, Afshin Zafari wrote:
>> 1. `ArrayAllocatorMallocLimit` is removed. The test cases that tested it
>> also are removed.
>> 2. `AllocArrayAllocator` instances are replaced with `MallocArrayAllocator`.
>> 3. The signature of `CHeapBitMap::free(ptr, size)` is kept
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 01:25:59 GMT, David Holmes wrote:
>> To expand if deadlock detection does not run at a safepoint then this logic
>> is non-atomic and completely broken:
>>
>> threads = VM.getVM().getThreads();
>> heap = VM.getVM().getObjectHeap();
>> createThreadTable(); // calls
On Tue, 26 Sep 2023 01:16:11 GMT, David Holmes wrote:
>> Edit: I missed the intermediate comments above where Roman explained.
>>
>> @plummercj the SA code sees T2 is pending on the monitor for object O, which
>> is locked anonymously but actually by T1. The SA code then goes hunting for
>>
On Tue, 26 Sep 2023 01:09:47 GMT, David Holmes wrote:
>> Surely jstack thread dump and deadlock check _has_ to run at a safepoint?
>
> Also isn't "anonymous locking" an intermediate step in monitor inflation? The
> inflated monitor becomes anonymously owned until the real owner sees it has
>
On Tue, 26 Sep 2023 01:07:32 GMT, David Holmes 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
On Mon, 25 Sep 2023 20:52:28 GMT, Chris Plummer wrote:
>> With the new lightweight locking, when a thread T1 holds a lightweight lock
>> on object O, and another thread T2 comes in and also wants to acquire that
>> lock, it inflates the lock to a monitor. And since it cannot determine which
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 monitors. Does it show one
>
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 19:18:38 GMT, Chris Plummer wrote:
>> Yes. But unless we run this at a safepoint, there is no consistent state
>> when we race with locking. I don't think we want to spam users with warnings
>> whenever we run into anonymous owners (which is not too infrequent).
>>
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 Mon, 25 Sep 2023 17:44:56 GMT, Chris Plummer 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 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, 18 Sep 2023 20:32:28 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 `-Djava.net.preferIPv6Addresses=true`
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
resolving an anonymous owner, we may not find one, because Java
On Tue, 19 Sep 2023 09:00:01 GMT, Fredrik Bredberg
wrote:
> Relativize initial_sp in interpreter frames.
>
> By changing the "initial_sp" (AKA "monitor_block_top" or "monitors" on
> PowerPC) member in interpreter frames from being an absolute address into an
> offset that is relative to the
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 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 Mon, 25 Sep 2023 03:40:53 GMT, David Holmes wrote:
>> Axel Boldt-Christmas has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Update copyright year
>
> test/hotspot/jtreg/serviceability/sa/TestObjectMonitorIterate.java line 1:
>
>> 1:
On Mon, 25 Sep 2023 02:08:36 GMT, David Holmes wrote:
>> Axel Boldt-Christmas has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Update copyright year
>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/ObjectSynchronizer.java
On Fri, 22 Sep 2023 02:40:39 GMT, David Holmes wrote:
>> Afshin Zafari has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> other size_t flags than the ArrayAllocatorMallocLimit are used in tests.
>
>
> 1. `ArrayAllocatorMallocLimit` is removed. The test cases that tested it also
> are removed.
> 2. `AllocArrayAllocator` instances are replaced with `MallocArrayAllocator`.
> 3. The signature of `CHeapBitMap::free(ptr, size)` is kept as it is, since it
> is called in this way from
On Fri, 22 Sep 2023 08:36:10 GMT, Jean-Philippe Bempel
wrote:
> increase Metaspace size and loop count to avoid OOME in nominal case
On my side, 17M with 500 iterations on an unpatched VM does not fail.
That's why I have boosted the number of iterations and increased the Metaspace
to magnify
38 matches
Mail list logo
