> This test iterates an array of ThreadInfos in a few places (e.g. in the
> method doCheck()), and needs to tolerate and ignore nulls, in case a thread
> finishes and the test hits an NPE.
>
> There are other calls like "TM.getThreadInfo(tid).getLockName()" which might
> often be risky, but if
> This test iterates an array of ThreadInfos in a few places (e.g. in the
> method doCheck()), and needs to tolerate and ignore nulls, in case a thread
> finishes and the test hits an NPE.
>
> There are other calls like "TM.getThreadInfo(tid).getLockName()" which might
> often be risky, but if
On Wed, 26 Jul 2023 20:14:16 GMT, Kevin Walls wrote:
>> This test iterates an array of ThreadInfos in a few places (e.g. in the
>> method doCheck()), and needs to tolerate and ignore nulls, in case a thread
>> finishes and the test hits an NPE.
>>
>> There are other calls like "TM.getThreadInf
On Wed, 26 Jul 2023 20:14:16 GMT, Kevin Walls wrote:
>> This test iterates an array of ThreadInfos in a few places (e.g. in the
>> method doCheck()), and needs to tolerate and ignore nulls, in case a thread
>> finishes and the test hits an NPE.
>>
>> There are other calls like "TM.getThreadInf
On Thu, 27 Jul 2023 17:00:22 GMT, Serguei Spitsyn wrote:
>> Thanks for the feedback, updated.
>> On this point, the method is only invoked on a very limited set of locks and
>> threads. It is called to examine LockAThread and LockBThread, and the test
>> main thread (if not virtual). So it wi
On Wed, 26 Jul 2023 20:14:16 GMT, Kevin Walls wrote:
>> This test iterates an array of ThreadInfos in a few places (e.g. in the
>> method doCheck()), and needs to tolerate and ignore nulls, in case a thread
>> finishes and the test hits an NPE.
>>
>> There are other calls like "TM.getThreadInf
On Wed, 26 Jul 2023 21:01:24 GMT, Kevin Walls wrote:
>> test/jdk/java/lang/management/ThreadMXBean/Locks.java line 474:
>>
>>> 472: lock = ownerInfo.getLockName();
>>> 473: continue;
>>> 474: }
>>
>> What happens if you don't exclude these ForkJoinPoo
On Thu, 27 Jul 2023 16:23:10 GMT, Serguei Spitsyn wrote:
> This looks pretty good to me. Is the test not failing anymore with your
> update?
Thanks Serguei, yes it's running reliably, including with virtual threads, with
this change (I just ran it, 50 times per platform, to re-check).
---
On Wed, 26 Jul 2023 20:14:16 GMT, Kevin Walls wrote:
>> This test iterates an array of ThreadInfos in a few places (e.g. in the
>> method doCheck()), and needs to tolerate and ignore nulls, in case a thread
>> finishes and the test hits an NPE.
>>
>> There are other calls like "TM.getThreadInf
On Wed, 26 Jul 2023 17:29:37 GMT, Chris Plummer wrote:
>> Kevin Walls has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Comment update
>
> test/jdk/java/lang/management/ThreadMXBean/Locks.java line 474:
>
>> 472: lock = ow
> This test iterates an array of ThreadInfos in a few places (e.g. in the
> method doCheck()), and needs to tolerate and ignore nulls, in case a thread
> finishes and the test hits an NPE.
>
> There are other calls like "TM.getThreadInfo(tid).getLockName()" which might
> often be risky, but if
On Wed, 21 Jun 2023 16:56:08 GMT, Kevin Walls wrote:
>> This test iterates an array of ThreadInfos in a few places (e.g. in the
>> method doCheck()), and needs to tolerate and ignore nulls, in case a thread
>> finishes and the test hits an NPE.
>>
>> There are other calls like "TM.getThreadInf
On Wed, 21 Jun 2023 16:56:08 GMT, Kevin Walls wrote:
>> This test iterates an array of ThreadInfos in a few places (e.g. in the
>> method doCheck()), and needs to tolerate and ignore nulls, in case a thread
>> finishes and the test hits an NPE.
>>
>> There are other calls like "TM.getThreadInf
On Thu, 22 Jun 2023 01:43:18 GMT, David Holmes wrote:
> Can you elaborate on this please. I'm unclear how the test knows whether a
> thread may be holding any locks or not, but why is locking a VirtualThread
> instance a special case??
Carriers are reported as waiting, the string representatio
On Wed, 21 Jun 2023 16:56:08 GMT, Kevin Walls wrote:
>> This test iterates an array of ThreadInfos in a few places (e.g. in the
>> method doCheck()), and needs to tolerate and ignore nulls, in case a thread
>> finishes and the test hits an NPE.
>>
>> There are other calls like "TM.getThreadInf
> This test iterates an array of ThreadInfos in a few places (e.g. in the
> method doCheck()), and needs to tolerate and ignore nulls, in case a thread
> finishes and the test hits an NPE.
>
> There are other calls like "TM.getThreadInfo(tid).getLockName()" which might
> often be risky, but if
On Wed, 21 Jun 2023 12:54:06 GMT, Kevin Walls wrote:
>> ThreadMXBean::getAllThreadsIds returns an array of the thread IDs of
>> platform threads, it doesn't include virtual threads, so I don't know why
>> this filter is added.
>
> Whitespace correction, thanks.
The filter was because of a fail
> This test iterates an array of ThreadInfos in a few places (e.g. in the
> method doCheck()), and needs to tolerate and ignore nulls, in case a thread
> finishes and the test hits an NPE.
>
> There are other calls like "TM.getThreadInfo(tid).getLockName()" which might
> often be risky, but if
On Wed, 21 Jun 2023 12:38:14 GMT, Alan Bateman wrote:
>> test/jdk/java/lang/management/ThreadMXBean/Locks.java line 72:
>>
>>> 70: .filter(Objects::nonNull)
>>> 71: .filter(i ->
>>> name.equals(i.getLockOwne
On Wed, 21 Jun 2023 12:33:46 GMT, Andrey Turbanov wrote:
>> This test iterates an array of ThreadInfos in a few places (e.g. in the
>> method doCheck()), and needs to tolerate and ignore nulls, in case a thread
>> finishes and the test hits an NPE.
>>
>> There are other calls like "TM.getThrea
On Thu, 15 Jun 2023 20:34:53 GMT, Kevin Walls wrote:
> This test iterates an array of ThreadInfos in a few places (e.g. in the
> method doCheck()), and needs to tolerate and ignore nulls, in case a thread
> finishes and the test hits an NPE.
>
> There are other calls like "TM.getThreadInfo(tid
This test iterates an array of ThreadInfos in a few places (e.g. in the method
doCheck()), and needs to tolerate and ignore nulls, in case a thread finishes
and the test hits an NPE.
There are other calls like "TM.getThreadInfo(tid).getLockName()" which might
often be risky, but if the threads
22 matches
Mail list logo
