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 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 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
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
