Re: RFR: 8316658: serviceability/jvmti/RedefineClasses/RedefineLeakThrowable.java fails intermittently
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 Re-testing at 17M/700 - PR Comment: https://git.openjdk.org/jdk/pull/15882#issuecomment-1734900165
Re: RFR: 8316417: ObjectMonitorIterator does not return the most recent monitor and is incorrect if no monitors exists [v6]
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 implementation can also not handle that the `_head` is nullptr >> (no monitors in the system) and returns a null ObjectMonitorIterator. Which >> is interpreted as `monitor list not supported, too old hotspot VM`. >> >> Changed the iterator to keep return the current monitor (starts with >> `_head`) and decoupled `_head == nullptr` from the question if >> ObjectMonitorIterator is supported. >> >> Testing: >> * Passes all `serviceability/sa` tests >> * Passed tier 1-5 >> * Passed GHA > > Axel Boldt-Christmas has updated the pull request incrementally with one > additional commit since the last revision: > > Update copyright year Looks good. Thanks - Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15782#pullrequestreview-1643345749
Re: RFR: 8316401: sun/tools/jhsdb/JStackStressTest.java failed with "InternalError: We should have found a thread that owns the anonymous lock"
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 with SA. The state is frozen, so SA can look at anything without > worrying about the state changing as it looks at it. When I say the JVM is > not in a consistent state, one example of that is when the JVM is in the > middle of an atomic operation when SA looks at it. Another example is when SA > looks at data that is normally only safe to look at when the VM is safe > pointing. The code that David pointed out is another example. It's usually > protected from observation by other threads by safe pointing, but SA can see > the data when it's in the middle of executing this code. Order may or may not > matter. Clearly the current order is problematic for SA. Switching the order > may or may not be a problem. It depends on whether SA cares that a monitor on > the lock_stack of one thread is shown to be owned by another thread. If that > does bre ak SA, I think SA might be able to recognize the situation and work around it, or just print a warning. > >> However, even that problem would be pre-existing (monitors not agreeing with >> each other or with threads), and do we currently print a warning about it? > > Likely not because it is likely not detected and doesn't result in some sort > of failure, and probably whoever wrote the original code hadn't considered > the possibility. Most of this type of SA error handling code (that result in > a warning) is the results of eventually someone noticing a failure of some > sort. If no one ever notices a failure, then the error handling is never > worked on. Ok! So we would have to swap the popping and state-update at least. Unless we insert members between them, the updates would still be observable in any order, I suppose, but inserting membars just to make SA happy seems a bit much. Can one of you try swapping and see if that makes the problem appear less often? I could not yet reproduce the bug at all. - PR Review Comment: https://git.openjdk.org/jdk/pull/15907#discussion_r1336628312
Re: RFR: 8316401: sun/tools/jhsdb/JStackStressTest.java failed with "InternalError: We should have found a thread that owns the anonymous lock"
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 consistent, not even if we swap the popping and owner-update, >> right? This is what you mean by inconsistent state, right? Or is there a way >> to get an atomic snapshot of threads *and* monitors? >> >> So yeah, we could print a warning when that happens. >> >> However, even that problem would be pre-existing (monitors not agreeing with >> each other or with threads), and do we currently print a warning about it? > > @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 with SA. The state is frozen, so SA can look at anything without worrying about the state changing as it looks at it. When I say the JVM is not in a consistent state, one example of that is when the JVM is in the middle of an atomic operation when SA looks at it. Another example is when SA looks at data that is normally only safe to look at when the VM is safe pointing. The code that David pointed out is another example. It's usually protected from observation by other threads by safe pointing, but SA can see the data when it's in the middle of executing this code. Order may or may not matter. Clearly the current order is problematic for SA. Switching the order may or may not be a problem. It depends on whether SA cares that a monitor on the lock_stack of one thread is shown to be owned by another thread. If that does break SA, I think SA might be able to recognize the situation and work around it, or just print a warning. > However, even that problem would be pre-existing (monitors not agreeing with > each other or with threads), and do we currently print a warning about it? Likely not because it is likely not detected and doesn't result in some sort of failure, and probably whoever wrote the original code hadn't considered the possibility. Most of this type of SA error handling code (that result in a warning) is the results of eventually someone noticing a failure of some sort. If no one ever notices a failure, then the error handling is never worked on. - PR Review Comment: https://git.openjdk.org/jdk/pull/15907#discussion_r1336627387
Re: RFR: 8316417: ObjectMonitorIterator does not return the most recent monitor and is incorrect if no monitors exists [v6]
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 should add to the list. >> >> If that was a requirement then both this and the previous implementation are >> completely broken. > >> 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 to deal with > (usually by falling on its face) is that the VM could be in an inconsistent > state, and there is no safe pointing, locking, or other synchronization it > can do to protect from that. Thanks - as per another SA issue my understanding of how the SA operated on a live process was incorrect. - PR Review Comment: https://git.openjdk.org/jdk/pull/15782#discussion_r1336625511
Re: RFR: 8316417: ObjectMonitorIterator does not return the most recent monitor and is incorrect if no monitors exists [v6]
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. So I > can write a proper test. > It does however seem very hard to write a proper test. Also not sure how to > make it non-flaky, maybe start a lingering App, let it reach steady state, > get the monitor list from some other API (maybe there is a jcmd, or we have > to use the whitebox API from the actual process and print it somewhere, and > hope the state of which monitors exists does not change), then attach the SA > and run and compare the lists. > > It seems hard to me to ensure that the SA agent prints all monitors in the > `_in_use_list` with a test. > > Or you would have to maintain a list of monitors for each locking mode and > the lingering app. Right. You would have to write the test as a state machine, very carefully orchestrating when monitors become in-use and when they cease to be in-use, and then attaching (the detaching) the SA when it reached each state and then checking the expected conditions for that state. Certainly a very non-trivial thing to try and do. - PR Review Comment: https://git.openjdk.org/jdk/pull/15782#discussion_r1336626565
Re: RFR: 8316401: sun/tools/jhsdb/JStackStressTest.java failed with "InternalError: We should have found a thread that owns the anonymous lock"
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 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 consistent, not even if we swap the popping and owner-update, > right? This is what you mean by inconsistent state, right? Or is there a way > to get an atomic snapshot of threads *and* monitors? > > So yeah, we could print a warning when that happens. > > However, even that problem would be pre-existing (monitors not agreeing with > each other or with threads), and do we currently print a warning about it? @rkennke the "snapshot" is atomic - the target VM is suspended. - PR Review Comment: https://git.openjdk.org/jdk/pull/15907#discussion_r1336621849
Re: RFR: 8316401: sun/tools/jhsdb/JStackStressTest.java failed with "InternalError: We should have found a thread that owns the anonymous lock"
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 issue, it would take 1000s of > iterations to reproduce. 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 consistent, not even if we swap the popping and owner-update, right? This is what you mean by inconsistent state, right? Or is there a way to get an atomic snapshot of threads *and* monitors? So yeah, we could print a warning when that happens. However, even that problem would be pre-existing (monitors not agreeing with each other or with threads), and do we currently print a warning about it? - PR Review Comment: https://git.openjdk.org/jdk/pull/15907#discussion_r1336609109
Re: RFR: 8316401: sun/tools/jhsdb/JStackStressTest.java failed with "InternalError: We should have found a thread that owns the anonymous lock"
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 bug quite a lot. Seems if the code in question was the issue, it would take 1000s of iterations to reproduce. - PR Review Comment: https://git.openjdk.org/jdk/pull/15907#discussion_r1336576620
Re: RFR: 8316401: sun/tools/jhsdb/JStackStressTest.java failed with "InternalError: We should have found a thread that owns the anonymous lock"
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 it still contains a reference to an anonymous monitor, but no thread >> actually owns the monitor (and the anonymous monitor is about to be purged >> from the cache). > > 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. - PR Review Comment: https://git.openjdk.org/jdk/pull/15907#discussion_r1336568286
Re: RFR: 8316401: sun/tools/jhsdb/JStackStressTest.java failed with "InternalError: We should have found a thread that owns the anonymous lock"
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 && monitor->is_owner_anonymous()) {
>> // It must be owned by us. Pop lock object from lock stack.
>> LockStack& lock_stack = current->lock_stack();
>> oop popped = lock_stack.pop();
>> assert(popped == object, "must be owned by this thread");
>> monitor->set_owner_from_anonymous(current);
>> }
>> monitor->exit(current);
>>
>> we should probably do this the other way around.
>
> 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 it still contains a reference to an anonymous monitor, but no thread
> actually owns the monitor (and the anonymous monitor is about to be purged
> from the cache).
Looks like you answered my question while I was asking it.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/15907#discussion_r1336566708
Re: RFR: 8316401: sun/tools/jhsdb/JStackStressTest.java failed with "InternalError: We should have found a thread that owns the anonymous lock"
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, 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 && monitor->is_owner_anonymous()) {
> // It must be owned by us. Pop lock object from lock stack.
> LockStack& lock_stack = current->lock_stack();
> oop popped = lock_stack.pop();
> assert(popped == object, "must be owned by this thread");
> monitor->set_owner_from_anonymous(current);
> }
> monitor->exit(current);
>
> we should probably do this the other way around.
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
it still contains a reference to an anonymous monitor, but no thread actually
owns the monitor (and the anonymous monitor is about to be purged from the
cache).
-
PR Review Comment: https://git.openjdk.org/jdk/pull/15907#discussion_r1336565875
Re: RFR: 8316401: sun/tools/jhsdb/JStackStressTest.java failed with "InternalError: We should have found a thread that owns the anonymous lock"
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 cannot change.
>>
>> Correct!
>>
>>> So in the current context the anonymous owner should be found ...
>>
>> That's what I concluded based on Roman's description of how things work.
>>
>>> I guess the question to be answered is how the code tries to find an
>>> anonymous owner? I'm not sure how you can find it.
>>
>> I'm not sure yet. I'll need to have a look.
>
> 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, 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 && monitor->is_owner_anonymous()) {
// It must be owned by us. Pop lock object from lock stack.
LockStack& lock_stack = current->lock_stack();
oop popped = lock_stack.pop();
assert(popped == object, "must be owned by this thread");
monitor->set_owner_from_anonymous(current);
}
monitor->exit(current);
we should probably do this the other way around.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/15907#discussion_r1336558790
Re: RFR: 8316401: sun/tools/jhsdb/JStackStressTest.java failed with "InternalError: We should have found a thread that owns the anonymous lock"
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 change. So in the current context the anonymous owner should be >> found ... I guess the question to be answered is how the code tries to find >> an anonymous owner? I'm not sure how you can find it. > >> 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. > > Correct! > >> So in the current context the anonymous owner should be found ... > > That's what I concluded based on Roman's description of how things work. > >> I guess the question to be answered is how the code tries to find an >> anonymous owner? I'm not sure how you can find it. > > I'm not sure yet. I'll need to have a look. 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. - PR Review Comment: https://git.openjdk.org/jdk/pull/15907#discussion_r1336557193
Re: RFR: 8316401: sun/tools/jhsdb/JStackStressTest.java failed with "InternalError: We should have found a thread that owns the anonymous lock"
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. Correct! > So in the current context the anonymous owner should be found ... That's what I concluded based on Roman's description of how things work. > I guess the question to be answered is how the code tries to find an > anonymous owner? I'm not sure how you can find it. I'm not sure yet. I'll need to have a look. - PR Review Comment: https://git.openjdk.org/jdk/pull/15907#discussion_r1336555978
Re: RFR: 8316401: sun/tools/jhsdb/JStackStressTest.java failed with "InternalError: We should have found a thread that owns the anonymous lock"
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 >> possible. But AFAICS the thread snapshot and heap snapshot are not atomic, >> so the set of threads could have changed, and the state of threads also. > >> Surely jstack thread dump and deadlock check _has_ to run at a safepoint? > > The reality is that JVM is rarely at a safepoint (unless perhaps when all > threads are blocked), and therefore jstack rarely is done at a safepoint. > This is the world SA lives in. The understanding is that SA debugging > features may give inaccurate info, or possibly not work at all. > >> 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. > > It doesn't snapshot. It does a debugger attach, which suspends the process. > It then starts to read in pages from the process to do things like jstack. > The process state does not change while it does this. It's not really any > different than gdb in this regard. gdb does not let the process state change > unless you use a command that allows execution such "step" or "continue". As > long as you avoid the commands that allow process execution, you can debug > without worrying about the process state changing. However, even GDB > debugging has the same issues with JVM safe pointing (or lack thereof). If > the JVM crashes and you start looking at certain data, it might be > inconsistent. There's no way to force a safepoint once there is a crash. > >> @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 >> the owner. But the VM is not standing still... > > The VM is standing still. There is no process execution while all of this > happens. jstack and the deadlock detection are fully executed while the JVM > process is halted. There is no JVM state change during any of this. 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. So in the current context the anonymous owner should be found ... I guess the question to be answered is how the code tries to find an anonymous owner? I'm not sure how you can find it. - PR Review Comment: https://git.openjdk.org/jdk/pull/15907#discussion_r1336549922
Re: RFR: 8299915: Remove ArrayAllocatorMallocLimit and associated code [v2]
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 as it is, since
>> it is called in this way from `GrowableBitMap::resize`, where `T` can be
>> also `ArenaBitMap` and `ResourceBitMap`. However, it uses
>> `MallocArrayAllocator::free(ptr)` and ignores the `size`:
>> ```C++
>> void CHeapBitMap::free(bm_word_t* map, idx_t size_in_words) const {
>> MallocArrayAllocator::free(map);
>> }
>>
>> ### Test
>> tiers1-4 passed on all platforms.
>
> 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.
test/hotspot/jtreg/serviceability/attach/AttachSetGetFlag.java line 62:
> 60: // Test a non-manageable size_t flag.
> 61: // Since it is not manageable, we can't test the setFlag
> functionality.
> 62: testGetFlag("StringDeduplicationCleanupDeadMinimum", "128");
A non-experimental flag, like MetaspaceSize, might be better long term in case
the experimental flag get removed again.
test/lib-test/jdk/test/whitebox/vm_flags/SizeTTest.java line 38:
> 36:
> 37: public class SizeTTest {
> 38: private static final String FLAG_NAME =
> "StringDeduplicationCleanupDeadMinimum";
Again a non-experimental flag, like MetaspaceSize, might be better here.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/15859#discussion_r1336545378
PR Review Comment: https://git.openjdk.org/jdk/pull/15859#discussion_r1336546774
Re: RFR: 8316401: sun/tools/jhsdb/JStackStressTest.java failed with "InternalError: We should have found a thread that owns the anonymous lock"
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 = VM.getVM().getObjectHeap(); > createThreadTable(); // calls getThreads() again > > The VM caches the set of threads ie the snapshot, so three sets are not > possible. But AFAICS the thread snapshot and heap snapshot are not atomic, so > the set of threads could have changed, and the state of threads also. > Surely jstack thread dump and deadlock check _has_ to run at a safepoint? The reality is that JVM is rarely at a safepoint (unless perhaps when all threads are blocked), and therefore jstack rarely is done at a safepoint. This is the world SA lives in. The understanding is that SA debugging features may give inaccurate info, or possibly not work at all. > 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. It doesn't snapshot. It does a debugger attach, which suspends the process. It then starts to read in pages from the process to do things like jstack. The process state does not change while it does this. It's not really any different than gdb in this regard. gdb does not let the process state change unless you use a command that allows execution such "step" or "continue". As long as you avoid the commands that allow process execution, you can debug without worrying about the process state changing. However, even GDB debugging has the same issues with JVM safe pointing (or lack thereof). If the JVM crashes and you start looking at certain data, it might be inconsistent. There's no way to force a safepoint once there is a crash. > @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 > the owner. But the VM is not standing still... The VM is standing still. There is no process execution while all of this happens. jstack and the deadlock detection are fully executed while the JVM process is halted. There is no JVM state change during any of this. - PR Review Comment: https://git.openjdk.org/jdk/pull/15907#discussion_r1336534342
Re: RFR: 8316401: sun/tools/jhsdb/JStackStressTest.java failed with "InternalError: We should have found a thread that owns the anonymous lock"
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 getThreads() again >> >> Without a stable VM you could have three almost completely different set of >> threads when each of these statements run! > > 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 = VM.getVM().getObjectHeap(); createThreadTable(); // calls getThreads() again The VM caches the set of threads ie the snapshot, so three sets are not possible. But AFAICS the thread snapshot and heap snapshot are not atomic, so the set of threads could have changed, and the state of threads also. - PR Review Comment: https://git.openjdk.org/jdk/pull/15907#discussion_r1336530626
Re: RFR: 8316401: sun/tools/jhsdb/JStackStressTest.java failed with "InternalError: We should have found a thread that owns the anonymous lock"
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 >> the owner. But the VM is not standing still. T1 continued execution and went >> to release the lock, it sees it has been inflated and sets itself as the >> true owner, then releases the lock thus clearing the owner and potentially >> unblocking T2. T2 could now proceed to acquire the lock. But the SA sees >> none of this because it has a stale view of things. > > 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 getThreads() again > > Without a stable VM you could have three almost completely different set of > threads when each of these statements run! 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. - PR Review Comment: https://git.openjdk.org/jdk/pull/15907#discussion_r1336527632
Re: RFR: 8316401: sun/tools/jhsdb/JStackStressTest.java failed with "InternalError: We should have found a thread that owns the anonymous lock"
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 > been inflated and updates the ownership accordingly. 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 getThreads() again Without a stable VM you could have three almost completely different set of threads when each of these statements run! - PR Review Comment: https://git.openjdk.org/jdk/pull/15907#discussion_r1336523076
Re: RFR: 8316401: sun/tools/jhsdb/JStackStressTest.java failed with "InternalError: We should have found a thread that owns the anonymous lock"
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 that when T1 starts the process of unlocking O, it sees the >> anonymous owner and it sets T1 as the owner before unlocking and handing off >> to T2. So I don't see how T1 could have "moved on". If T2 is blocked on O >> and O an anonymous owner, then T1 must still own it. >> >> SA always deals with a snapshot of the JVM state. Once SA attaches, no >> threads are running. So if O has an anonymous owner, you don't have to worry >> about the owner releasing the monitor while you are looking for the owner. >> >> The question then becomes is there a short window while releasing the >> monitor that O still shows up as having an anonymous owner, but T1 has >> already released it. From your description of the order of things, this >> doesn't seem possible. > > 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 been inflated and updates the ownership accordingly. - PR Review Comment: https://git.openjdk.org/jdk/pull/15907#discussion_r1336520272
Re: RFR: 8316401: sun/tools/jhsdb/JStackStressTest.java failed with "InternalError: We should have found a thread that owns the anonymous lock"
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 >> threads currently locks O, it installs a special owner - which we call >> anonymous owner - in the ObjectMonitor, it basically means 'we don't know'. >> As soon as T1 unlocks O, it observes that the lock is now inflated and set >> to anonymous owner, installs itself as the proper owner of the ObjectMonitor >> and proceeds to unlock the ObjectMonitor - thereby handing over ownership to >> T2. >> >> 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. >> >> However, the race is more general, and pre-(lightweight-locking-)existing: >> if SA observes a locked object, or a thread which holds a particular lock, >> by the time it is reporting, this information may (likely) be wrong because >> the thread has, in the meantime, moved on. This in itself may not be a big >> problem. What may be worse is that, if SA prints stacks of all threads and >> also prints locking information, the overall information may be >> *inconsistent*. For example, it may report that two threads hold the same >> object. >> Also, I am not sure how deep SA goes. Telling from the stack-trace in the >> original report, it looks like there is a DeadlockDetector involved. If >> threads don't hold still while we try to detect deadlocks, we may report >> false positives. (We would perhaps not report false negatives, because >> deadlocked thread by definition don't move ;-) ) >> >> I don't know enough about SA and how it deals with locking to judge how much >> of a problem all that is, but I think the pre-existing code (before LW >> locking) did not warn about locking raciness, and I don't really see that we >> should do this for the anonymous case. > >> 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 starts the process of unlocking O, it sees the > anonymous owner and it sets T1 as the owner before unlocking and handing off > to T2. So I don't see how T1 could have "moved on". If T2 is blocked on O and > O an anonymous owner, then T1 must still own it. > > SA always deals with a snapshot of the JVM state. Once SA attaches, no > threads are running. So if O has an anonymous owner, you don't have to worry > about the owner releasing the monitor while you are looking for the owner. > > The question then becomes is there a short window while releasing the monitor > that O still shows up as having an anonymous owner, but T1 has already > released it. From your description of the order of things, this doesn't seem > possible. Surely jstack thread dump and deadlock check _has_ to run at a safepoint? - PR Review Comment: https://git.openjdk.org/jdk/pull/15907#discussion_r1336519288
Re: RFR: 8316417: ObjectMonitorIterator does not return the most recent monitor and is incorrect if no monitors exists [v6]
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 > after your fix? I just tried with your fix and now it shows one monitor: Monitor Cache Dump (not including JVMTI raw monitors): ObjectMonitor@0x7f26040010b0 _header: 0x1 _object: 0xa0001750, a java/lang/ref/NativeReferenceQueue$Lock _owner: null _contentions: 0 _waiters: 1 _recursions: 0 - PR Review Comment: https://git.openjdk.org/jdk/pull/15782#discussion_r1336408860
Re: RFR: 8316401: sun/tools/jhsdb/JStackStressTest.java failed with "InternalError: We should have found a thread that owns the anonymous lock"
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 starts the process of unlocking O, it sees the anonymous owner and it sets T1 as the owner before unlocking and handing off to T2. So I don't see how T1 could have "moved on". If T2 is blocked on O and O an anonymous owner, then T1 must still own it. SA always deals with a snapshot of the JVM state. Once SA attaches, no threads are running. So if O has an anonymous owner, you don't have to worry about the owner releasing the monitor while you are looking for the owner. The question then becomes is there a short window while releasing the monitor that O still shows up as having an anonymous owner, but T1 has already released it. From your description of the order of things, this doesn't seem possible. - PR Review Comment: https://git.openjdk.org/jdk/pull/15907#discussion_r1336377708
Re: RFR: 8316401: sun/tools/jhsdb/JStackStressTest.java failed with "InternalError: We should have found a thread that owns the anonymous lock"
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). >> Existing (pre-lightweight-) locking doesn't print warnings either, when a >> thread that's expected to lock on an object has moved on or otherwise >> encounters racy state. > > I need a better understanding of anonymous owners and the race you think is > going on here. 99+% of the time if we are not at a safepoint, pretty much > everything still works fine with SA. Safe points guarantee safe access, but > not being at a safepoint does not guarantee there will be an issue for SA. It > usually still works, and we try to report when it doesn't. 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 threads currently locks O, it installs a special owner - which we call anonymous owner - in the ObjectMonitor, it basically means 'we don't know'. As soon as T1 unlocks O, it observes that the lock is now inflated and set to anonymous owner, installs itself as the proper owner of the ObjectMonitor and proceeds to unlock the ObjectMonitor - thereby handing over ownership to T2. 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. However, the race is more general, and pre-(lightweight-locking-)existing: if SA observes a locked object, or a thread which holds a particular lock, by the time it is reporting, this information may (likely) be wrong because the thread has, in the meantime, moved on. This in itself may not be a big problem. What may be worse is that, if SA prints stacks of all threads and also prints locking information, the overall information may be *inconsistent*. For example, it may report that two threads hold the same object. Also, I am not sure how deep SA goes. Telling from the stack-trace in the original report, it looks like there is a DeadlockDetector involved. If threads don't hold still while we try to detect deadlocks, we may report false positives. (We would perhaps not report false negatives, because deadlocked thread by definition don't move ;-) ) I don't know enough about SA and how it deals with locking to judge how much of a problem all that is, but I think the pre-existing code (before LW locking) did not warn about locking raciness, and I don't really see that we should do this for the anonymous case. - PR Review Comment: https://git.openjdk.org/jdk/pull/15907#discussion_r1336332299
Re: RFR: 8316401: sun/tools/jhsdb/JStackStressTest.java failed with "InternalError: We should have found a thread that owns the anonymous lock"
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 precise, so we return null here. >>> 247: return null; >> >> If the JVM is in a consistent state, do we expect that this should not >> happen? If so, then a warning message would be the usual SA approach. >> Basically let the user know we detected an issue rather than just quietly >> succeeding. > > 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). Existing > (pre-lightweight-) locking doesn't print warnings either, when a thread > that's expected to lock on an object has moved on or otherwise encounters > racy state. I need a better understanding of anonymous owners and the race you think is going on here. 99+% of the time if we are not at a safepoint, pretty much everything still works fine with SA. Safe points guarantee safe access, but not being at a safepoint does not guarantee there will be an issue for SA. It usually still works, and we try to report when it doesn't. - PR Review Comment: https://git.openjdk.org/jdk/pull/15907#discussion_r1336297000
Re: RFR: 8316401: sun/tools/jhsdb/JStackStressTest.java failed with "InternalError: We should have found a thread that owns the anonymous lock"
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. >> When resolving an anonymous owner, we may not find one, because Java threads >> may already have moved on. Instead of crashing with a stacktrace, we should >> gracefully return null here. >> >> Testing: >> - [x] sun/tools/jhsdb/JStackStressTest.java >> - [x] sun/tools/jhsdb >> - [x] serviceability/sa > > 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 precise, so we return null here. >> 247: return null; > > If the JVM is in a consistent state, do we expect that this should not > happen? If so, then a warning message would be the usual SA approach. > Basically let the user know we detected an issue rather than just quietly > succeeding. 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). Existing (pre-lightweight-) locking doesn't print warnings either, when a thread that's expected to lock on an object has moved on or otherwise encounters racy state. - PR Review Comment: https://git.openjdk.org/jdk/pull/15907#discussion_r1336253796
Re: RFR: 8316401: sun/tools/jhsdb/JStackStressTest.java failed with "InternalError: We should have found a thread that owns the anonymous lock"
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 > resolving an anonymous owner, we may not find one, because Java threads may > already have moved on. Instead of crashing with a stacktrace, we should > gracefully return null here. > > Testing: > - [x] sun/tools/jhsdb/JStackStressTest.java > - [x] sun/tools/jhsdb > - [x] serviceability/sa 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 precise, so we return null here. > 247: return null; If the JVM is in a consistent state, do we expect that this should not happen? If so, then a warning message would be the usual SA approach. Basically let the user know we detected an issue rather than just quietly succeeding. - PR Review Comment: https://git.openjdk.org/jdk/pull/15907#discussion_r1336208858
Integrated: JDK-8313804: JDWP support for -Djava.net.preferIPv6Addresses=system
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` and > `-Djava.net.preferIPv6Addresses=false`. This pull request has now been integrated. Changeset: 9291b46b Author:Liam Miller-Cushon URL: https://git.openjdk.org/jdk/commit/9291b46bcfa76a596578eb50c29b9850e7020dea Stats: 117 lines in 2 files changed: 98 ins; 0 del; 19 mod 8313804: JDWP support for -Djava.net.preferIPv6Addresses=system Reviewed-by: cjplummer, amenkov - PR: https://git.openjdk.org/jdk/pull/15796
RFR: 8316401: sun/tools/jhsdb/JStackStressTest.java failed with "InternalError: We should have found a thread that owns the anonymous lock"
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 threads may already have moved on. Instead of crashing with a stacktrace, we should gracefully return null here. Testing: - [x] sun/tools/jhsdb/JStackStressTest.java - [x] sun/tools/jhsdb - [x] serviceability/sa - Commit messages: - 8316401: sun/tools/jhsdb/JStackStressTest.java failed with "InternalError: We should have found a thread that owns the anonymous lock" Changes: https://git.openjdk.org/jdk/pull/15907/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15907&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8316401 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15907.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15907/head:pull/15907 PR: https://git.openjdk.org/jdk/pull/15907
Re: RFR: 8315966: Relativize initial_sp in interpreter frames
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 frame pointer, we don't need to change the > value as we freeze and thaw frames of virtual threads. This is since we might > freeze and thaw from and to different worker threads, so the absolute address > to locals might change, but the offset from the frame pointer will be > constant. > > This subtask only handles relativization of "initial_sp" and > "monitor_block_top" since it's the same slot in interpreter frames (roughly > the same as "monitors" on PowerPC). Relativization of other interpreter frame > members are handled in other subtasks to JDK-8289296. > > Tested tier1-tier7 on supported platforms. The rest was sanity tested using > Qemu. x86 and AArch64 parts look good to me. Thanks, Patricio - Marked as reviewed by pchilanomate (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15815#pullrequestreview-1642348863
Re: RFR: 8316417: ObjectMonitorIterator does not return the most recent monitor and is incorrect if no monitors exists [v6]
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 implementation can also not handle that the `_head` is nullptr
>> (no monitors in the system) and returns a null ObjectMonitorIterator. Which
>> is interpreted as `monitor list not supported, too old hotspot VM`.
>>
>> Changed the iterator to keep return the current monitor (starts with
>> `_head`) and decoupled `_head == nullptr` from the question if
>> ObjectMonitorIterator is supported.
>>
>> Testing:
>> * Passes all `serviceability/sa` tests
>> * Passed tier 1-5
>> * Passed GHA
>
> 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/ui/MonitorCacheDumpPanel.java
line 101:
> 99: tty.println("You need 1.4.0_04, 1.4.1_01 or later versions");
> 100: return;
> 101: }
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 after your
fix?
-
PR Review Comment: https://git.openjdk.org/jdk/pull/15782#discussion_r1335978134
Re: RFR: 8316417: ObjectMonitorIterator does not return the most recent monitor and is incorrect if no monitors exists [v6]
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 to deal with (usually by falling on its face) is that the VM could be in an inconsistent state, and there is no safe pointing, locking, or other synchronization it can do to protect from that. - PR Review Comment: https://git.openjdk.org/jdk/pull/15782#discussion_r1335968189
Re: RFR: 8316417: ObjectMonitorIterator does not return the most recent monitor and is incorrect if no monitors exists [v6]
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: /* > > This test still barely actually tests the iterator code. Agreed. Did not want to spend time learning the SA, but maybe I should. So I can write a proper test. It does however seem very hard to write a proper test. Also not sure how to make it non-flaky, maybe start a lingering App, let it reach steady state, get the monitor list from some other API (maybe there is a jcmd, or we have to use the whitebox API from the actual process and print it somewhere, and hope the state of which monitors exists does not change), then attach the SA and run and compare the lists. It seems hard to me to ensure that the SA agent prints all monitors in the `_in_use_list` with a test. Or you would have to maintain a list of monitors for each locking mode and the lingering app. - PR Review Comment: https://git.openjdk.org/jdk/pull/15782#discussion_r1335687908
Re: RFR: 8316417: ObjectMonitorIterator does not return the most recent monitor and is incorrect if no monitors exists [v6]
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
> line 49:
>
>> 47: Type monitorListType = db.lookupType("MonitorList");
>> 48: Address monitorListAddr =
>> objectSynchronizerType.getField("_in_use_list").getStaticFieldAddress();
>> 49: inUseListHead =
>> monitorListType.getAddressField("_head").getAddress(monitorListAddr);
>
> So is `inUseListHead` effectively a "pointer" to the `_head` field of the
> `_in_use_list` `MonitorList`, which is dereferenced when we read it? Else I'm
> not seeing how we iterate the current set of in-use monitors.
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 should add to
the list.
If that was a requirement then both this and the previous implementation are
completely broken.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/15782#discussion_r1335673227
Re: RFR: 8299915: Remove ArrayAllocatorMallocLimit and associated code [v2]
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.
>
> test/hotspot/jtreg/serviceability/attach/AttachSetGetFlag.java line 64:
>
>> 62: testGetFlag("ArrayAllocatorMallocLimit", "128");
>> 63: // testSetFlag("ArrayAllocatorMallocLimit", "64", "128");
>> 64:
>
> You need to replace this with another non-manageable size_t flag so that code
> coverage is maintained.
Fixed.
> test/lib-test/jdk/test/whitebox/vm_flags/SizeTTest.java line 1:
>
>> 1: /*
>
> This test also should not be removed but changed to use a different size_t
> flag so that the WB functionality continues to be tested for a flag of this
> type.
Fixed.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/15859#discussion_r1335611692
PR Review Comment: https://git.openjdk.org/jdk/pull/15859#discussion_r1335611842
Re: RFR: 8299915: Remove ArrayAllocatorMallocLimit and associated code [v2]
> 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 `GrowableBitMap::resize`, where `T` can be also
> `ArenaBitMap` and `ResourceBitMap`. However, it uses
> `MallocArrayAllocator::free(ptr)` and ignores the `size`:
> ```C++
> void CHeapBitMap::free(bm_word_t* map, idx_t size_in_words) const {
> MallocArrayAllocator::free(map);
> }
>
> ### Test
> tiers1-4 passed on all platforms.
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.
-
Changes:
- all: https://git.openjdk.org/jdk/pull/15859/files
- new: https://git.openjdk.org/jdk/pull/15859/files/3371127f..623d076f
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=15859&range=01
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=15859&range=00-01
Stats: 55 lines in 2 files changed: 55 ins; 0 del; 0 mod
Patch: https://git.openjdk.org/jdk/pull/15859.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/15859/head:pull/15859
PR: https://git.openjdk.org/jdk/pull/15859
Re: RFR: 8316658: serviceability/jvmti/RedefineClasses/RedefineLeakThrowable.java fails intermittently
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 the leak and also avoid fixed cost of loading test infrastructure into Metaspace. I have tested 17M/700 iterations successfully - PR Comment: https://git.openjdk.org/jdk/pull/15882#issuecomment-1733036149
